Unable to deactivate the authorization, followed by invalid response and issue failure

Hi. I'm running into a surprising issue where it looks like LetsEncrypt is challanging me to provide solutions for domains for which I am not trying to obtain a certificate.

In particular, the following lines in my output logs raise suspicion:

[ampelmann.nl] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/10601900716
...
Deactivating auth: https://acme-v02.api.letsencrypt.org/acme/authz-v3/10601900716
Unable to deactivate the authorization: https://acme-v02.api.letsencrypt.org/acme/authz-v3/10601900716
...
[ampelmann.nl] acme: error: 403 :: urn:ietf:params:acme:error:unauthorized :: Invalid response from https://va-acm.heroku.com/challenge?host=www.ampelmann.nl&token=ACSy20sBQlnxg_TYhSZ2p8n5h6Oa9OL7fScchg3kgNg

I'm noticing when visiting https://acme-v02.api.letsencrypt.org/acme/authz-v3/10601900716 that it includes validation records for www.ampelmann.nl and va-acm.heroku.com. Both appear to be related to the www subdomain of the domain I'm trying to obtain a certificate for. Note that the subdomain does have a webserver attached to it, and the certificate is "managed automatically" by Heroku. That same Heroku service also tried to obtain a certificate for ampelmann.nl earlier today, but now has been reconfigured to care only about the www subdomain.

The last line there shows that that challange fails (of course, because the www subdomain points to a completely different server). I'm not sure when this www subdomain is introduced to the validation procedure, but it seems to be the reason for not being able to obtain a certificate for the parent domain.

Technical information below. Any help is much appreciated. :slight_smile:


My domain is: ampelmann.nl

I ran this command:

lego --accept-tos --http --email 'it-team@wearereasonablepeople.com' --path /var/lib/acme/.lego/ --http.webroot /var/lib/acme/acme-challenge/ --domains ampelmann.nl run
  • I didn't run this command directly. It was generated by an abstraction which wrapped it in a systemd service.

It produced this output:

Feb 04 15:02:40 redirector acme-ampelmann.nl-start[4852]: 2021/02/04 15:02:40 No key found for account it-team@wearereasonablepeople.com. Generating a P256 key.
Feb 04 15:02:40 redirector acme-ampelmann.nl-start[4852]: 2021/02/04 15:02:40 Saved key to accounts/acme-v02.api.letsencrypt.org/it-team@wearereasonablepeople.com/keys/it-team@wearereasonablepeople.com.key
Feb 04 15:02:41 redirector acme-ampelmann.nl-start[4852]: 2021/02/04 15:02:41 [INFO] acme: Registering account for it-team@wearereasonablepeople.com
Feb 04 15:02:41 redirector acme-ampelmann.nl-start[4852]: !!!! HEADS UP !!!!
Feb 04 15:02:41 redirector acme-ampelmann.nl-start[4852]: Your account credentials have been saved in your Let's Encrypt
Feb 04 15:02:41 redirector acme-ampelmann.nl-start[4852]: configuration directory at "accounts".
Feb 04 15:02:41 redirector acme-ampelmann.nl-start[4852]: You should make a secure backup of this folder now. This
Feb 04 15:02:41 redirector acme-ampelmann.nl-start[4852]: configuration directory will also contain certificates and
Feb 04 15:02:41 redirector acme-ampelmann.nl-start[4852]: private keys obtained from Let's Encrypt so making regular
Feb 04 15:02:41 redirector acme-ampelmann.nl-start[4852]: backups of this folder is ideal.
Feb 04 15:02:41 redirector acme-ampelmann.nl-start[4852]: 2021/02/04 15:02:41 [INFO] [ampelmann.nl] acme: Obtaining bundled SAN certificate
Feb 04 15:02:41 redirector acme-ampelmann.nl-start[4852]: 2021/02/04 15:02:41 [INFO] [ampelmann.nl] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/10601900716
Feb 04 15:02:41 redirector acme-ampelmann.nl-start[4852]: 2021/02/04 15:02:41 [INFO] [ampelmann.nl] acme: Could not find solver for: tls-alpn-01
Feb 04 15:02:41 redirector acme-ampelmann.nl-start[4852]: 2021/02/04 15:02:41 [INFO] [ampelmann.nl] acme: use http-01 solver
Feb 04 15:02:41 redirector acme-ampelmann.nl-start[4852]: 2021/02/04 15:02:41 [INFO] [ampelmann.nl] acme: Trying to solve HTTP-01
Feb 04 15:02:47 redirector acme-ampelmann.nl-start[4852]: 2021/02/04 15:02:47 [INFO] Deactivating auth: https://acme-v02.api.letsencrypt.org/acme/authz-v3/10601900716
Feb 04 15:02:48 redirector acme-ampelmann.nl-start[4852]: 2021/02/04 15:02:48 [INFO] Unable to deactivate the authorization: https://acme-v02.api.letsencrypt.org/acme/authz-v3/10601900716
Feb 04 15:02:48 redirector acme-ampelmann.nl-start[4852]: 2021/02/04 15:02:48 Could not obtain certificates:
Feb 04 15:02:48 redirector acme-ampelmann.nl-start[4852]:         error: one or more domains had a problem:
Feb 04 15:02:48 redirector acme-ampelmann.nl-start[4852]: [ampelmann.nl] acme: error: 403 :: urn:ietf:params:acme:error:unauthorized :: Invalid response from https://va-acm.heroku.com/challenge?host=www.ampelmann.nl&token=ACSy20sBQlnxg_TYhSZ2p8n5h6Oa9OL7fScchg3kgNg [54.159.216.156]: 404, url:
Feb 04 15:02:48 redirector systemd[1]: acme-ampelmann.nl.service: Main process exited, code=exited, status=1/FAILURE
Feb 04 15:02:48 redirector systemd[1]: acme-ampelmann.nl.service: Failed with result 'exit-code'.
Feb 04 15:02:48 redirector systemd[1]: Failed to start Renew ACME certificate for ampelmann.nl.
Feb 04 15:02:48 redirector systemd[1]: acme-ampelmann.nl.service: Consumed 92ms CPU time, received 15.6K IP traffic, sent 7.3K IP traffic.

My web server is (include version): nginx/1.16.1

The operating system my web server runs on is (include version): NixOS 20.09

My hosting provider, if applicable, is: DigitalOcean

I can login to a root shell on my machine (yes or no, or I don't know): Yes.

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): No.

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): Using lego

Hi @avaq

that's the result of your configuration - see https://check-your-website.server-daten.de/?q=ampelmann.nl#url-checks

Your http + non-www redirects to https + www, then to Heroku.

If you don't want that, remove that redirect.

1 Like

Thank you for taking a look @JuergenAuer. I had not considered that. I did check my nginx configuration, and I assumed that the .well-known location there would not be redirected.

        server {
                listen 0.0.0.0:443 ssl http2 default_server ;
                listen [::]:443 ssl http2 default_server ;
                listen 0.0.0.0:80 default_server ;
                listen [::]:80 default_server ;
                server_name ampelmann.nl ;
                location /.well-known/acme-challenge {
                        root /var/lib/acme/acme-challenge;
                        auth_basic off;
                }
                return 301 https://www.ampelmann.nl$request_uri;
                ssl_certificate /var/lib/acme/ampelmann.nl/fullchain.pem;
                ssl_certificate_key /var/lib/acme/ampelmann.nl/key.pem;
                ssl_trusted_certificate /var/lib/acme/ampelmann.nl/chain.pem;
        }
1 Like

Nesting that statement into a location / {} directive did indeed solve the issue. Thanks again.

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.