Unable to Renew Certificate with Multiple Names


#1

My domain is: quarkstat.com, aws.jander.me

I ran this command:

docker run -it --rm -p 4343:443 -p 8080:80 --name certbot             
     -v "/etc/letsencrypt:/etc/letsencrypt"
     -v "/var/lib/letsencrypt:/var/lib/letsencrypt"             
     quay.io/letsencrypt/letsencrypt:latest renew --dry-run

It produced this output:

 - The following errors were reported by the server:

   Domain: quarkstat.com
   Type:   unauthorized
   Detail: Incorrect validation certificate for TLS-SNI-01 challenge.
   Requested
   9e7f5e778a7148b8856b9361985e61c1.fc52b1a533fc3e1afcb7e8367f8784df.acme.invalid
   from 35.160.186.36:443. Received certificate containing
   'aws.jander.me, quarkstat.com'

   Domain: aws.jander.me
   Type:   unauthorized
   Detail: Incorrect validation certificate for TLS-SNI-01 challenge.
   Requested
   cdd13f47fa7c9344470b9bef97804fc5.ee1068c90540b5516f818748f15fb0b2.acme.invalid
   from 35.160.186.36:443. Received certificate containing
   'aws.jander.me, quarkstat.com'

My operating system is (include version): linux AWS AMI

My web server is (include version): nginx

My hosting provider, if applicable, is: AWS

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

First off, thanks for the great work you’re doing! I’ve just stumbled on your service in the past week and have been working to get it setup in a test environment. At this point I’m struggling with the renewal of a certificate created with multiple names.

Concern/Question: Since there is a single SAN certificate use for both domains here, shouldn’t this validation be considered successful? i.e. the SAN cert returned in both case did include the domain name being validated.

My nginx conf is similar to that described in this article with the following relevant sections from the configuration showing that the requests to /.well-known are proxied through to the certbot docker container

 server {
    listen       80;
    server_name quarkstat.com aws.jander.me;
    location /.well-known {
    	proxy_pass http://127.0.0.1:8080/;
    }

     return 301 https://$server_name$request_uri;
 }

  server {
      listen 443 ssl;
      server_name quarkstat.com aws.jander.me;

      ssl_certificate      /etc/letsencrypt/live/quarkstat.com/fullchain.pem;
      ssl_certificate_key  /etc/letsencrypt/live/quarkstat.com/privkey.pem;
      ssl_session_cache    shared:SSL:1m;
      ssl_session_timeout  5m;
      ssl_ciphers  HIGH:!aNULL:!MD5;
      ssl_prefer_server_ciphers  on;

      location /.well-known {
          proxy_pass http://127.0.0.1:4343/;
      }

 }

#2

Something seems to have changed in certbot 0.10.1, I used the same command I have been using for months to generate some new certs yesterday and got the same error message as you.

I was not in the mood to go digging so I just did this which solved it very quickly for me but I will see later this week why it is failing. For now a quick stop of nginx (not desirable for some) and then running it with the standalone web server is a quick fix, only took me 15 seconds of downtime to generate 3 new certs.

sudo service nginx stop
sudo ./certbot-auto --standalone .......
sudo service nginx restart

#3

I think you may need to add the --preferred-challenges http option to the first command, as the default tls-sni challenge doesn’t work with the technique of proxying the .well-known directory. The tls-sni challenge requires the client to present a certificate for a nonsense domain, something.somethingelse.acme.invalid, but nginx presents the site’s ordinary certificate before passing the connection through to certbot, so the challenge fails.

Or you can just do what @MitchellK describes, if you don’t mind stopping nginx briefly when renewing.


#4

Thanks @jmorahan I think that is the key, that was never needed before. Will try later this week when I get back from my little break away and confirm.


#5

Thank you both! I’ll give this a try shortly but the explanation makes sense.


#6

I have the same problem when trying to perform a dry-run. When I add --preferred-challenges http option request is proxied to 404 error. Any info on how to overcome this problem?

As a side note, I tried to manually create .well-known/acme-challenge and change permissions to 755 with no luck.

Strange things happen… After logging again to server and trying again now I get 502 - bad gateway…


#7

Are you sure you’re having the exact same problem? We’d need to see your nginx configuration and the exact command(s) you ran to be sure. You might be better off posting this information in a new thread though.


#8

I created a new thread, but belive it is the same error.


#9

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