Failure during auto renew

Help
1

3 months ago I was was able to get help on this site (NGINX - HTTP Challenges Not Passing Due To MIME Types)

I’m now having trouble auto renewing. At the command line in my server I have:

deploy@server:/var/www/html$ sudo certbot certonly --webroot -w /var/www/html --agree-tos --email myname@yahoo.com -d example.com -d www.example.com --non-interactive
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Cert is due for renewal, auto-renewing...
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for example.com
http-01 challenge for www.example.com
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. example.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https:example.com/.well-known/acme-challenge/1VaN2LTem5XC0gIg6GSFbqzqJRfQGCsUIlyN-r-w-N4: Error getting validation data, www.example.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https:example.com/.well-known/acme-challenge/EoV_mK2ryxJB5IJc6AubNbnj5XYO3JdVQK7i495mk68: Error getting validation data

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: example.com
   Type:   connection
   Detail: Fetching
   https:example.com/.well-known/acme-challenge/1VaN2LTem5XC0gIg6GSFbqzqJRfQGCsUIlyN-r-w-N4:
   Error getting validation data

   Domain: www.example.com
   Type:   connection
   Detail: Fetching
   https:example.com/.well-known/acme-challenge/EoV_mK2ryxJB5IJc6AubNbnj5XYO3JdVQK7i495mk68:
   Error getting validation data

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.
deploy@server:/var/www/html$ Error getting validation data

I may have changed my server config in the meantime it includes in my nginx.conf:

                                                        X
 server {
 listen 80;
 server_name example.com www.example.com;
 return 301 https:$server_name$request_uri;


 }

 server {
     listen 443 ssl http2;
     server_name example.com www.example.com;
     root /var/www/html;

 location /static {
     alias /home/deploy/sites/example.com/static;
 }
 location / {
     proxy_set_header Host $host;
     proxy_pass http://unix:/tmp/mysocket.socket;
 }

 location ^~ /.well-known/acme-challenge/ {
         default_type "text/plain";
             root /var/www/html;
 }
 ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Can anyone advise me on what to try next?

2

Do you, by any chance, have any AAAA records for this domain, and a server that is not properly responding to IPv6 requests?

3

I’m trying to run “certbot-auto certonly --manual”, the same exact command I ran 3 months ago and 6 months ago, and am getting the same errors as you.

Could be a bug with the latest version of of certbot-auto or could be something with whatever they’re using to connect to the URLs.

No AAAA records or IPv6 setup anywhere. As I mentioned, it worked 3 and 6 months ago, and no changes have been made anywhere in the DNS or in any config files since then.

It’s very sporadic too. I’ve tried to run the command 3 times now, and am trying to renew 9 subdomains at once, and each time it shows different ones having failed.

Alright, after trying again, I’m getting a new error: “Error creating new authz”

So it definitely seems to be an issue on the https://acme-v01.api.letsencrypt.org side of things. Hopefully it’s able to resolve itself… I procrastinated and my current certs are only valid until 22:52 GMT on August 9th. :frowning:

4

Looks like we’re not going crazy, @kc1! https://letsencrypt.status.io

14 AM
Screen Shot 2017-08-09 at 12.23.14 AM.png1832×1114 237 KB

5

Capture
Capture.PNG1265×729 44.3 KB

Hi guys,

Thanks for your help on this. I’m still getting the same error. The screenshot of the letsencrypt system status says operational in the screenshot I just took. heres the output:

  deploy@server:~$ sudo certbot certonly --webroot -w /var/www/html --agree-tos --email myname@yahoo.com -d example.com -d www.example.com --non-interactive
  [sudo] password for deploy:
  Saving debug log to /var/log/letsencrypt/letsencrypt.log
  Cert is due for renewal, auto-renewing...
  Renewing an existing certificate
  Performing the following challenges:
  http-01 challenge for example.com
  http-01 challenge for www.example.com
  Using the webroot path /var/www/html for all unmatched domains.
  Waiting for verification...
  Cleaning up challenges
  Failed authorization procedure. www.example.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https:example.com/.well-known/acme-challenge/sg9GfHvH_kYs2vrW0U3zSDk4K3VnXuDMNZgBslqaUzE: Error getting validation data, example.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https:example.com/.well-known/acme-challenge/CqJurh_JEBI1idOI5U8xyORFG_xsIWDsZj7Zg62Cg9c: Error getting validation data

  IMPORTANT NOTES:
   - The following errors were reported by the server:

     Domain: www.example.com
     Type:   connection
     Detail: Fetching
     https:example.com/.well-known/acme-challenge/sg9GfHvH_kYs2vrW0U3zSDk4K3VnXuDMNZgBslqaUzE:
     Error getting validation data

     Domain: example.com
     Type:   connection
     Detail: Fetching
     https:example.com/.well-known/acme-challenge/CqJurh_JEBI1idOI5U8xyORFG_xsIWDsZj7Zg62Cg9c:
     Error getting validation data

     To fix these errors, please make sure that your domain name was
     entered correctly and the DNS A record(s) for that domain
     contain(s) the right IP address. Additionally, please check that
     your computer has a publicly routable IP address and that no
     firewalls are preventing the server from communicating with the
     client. If you're using the webroot plugin, you should also verify
     that you are serving files from the webroot path you provided.

Should I give it more time ? Also I’ve not set up an AAAA record before (this is the first time hearing of this) .

As a beginner in this, @jared.m , why did you suspect an ipv6 problem from my output?

Thanks,

KC

6

@kc1 Is that the actual output or did you modify it? Meaning did you replace the actual domain names in the output with example.com, or is that literally what it says?

Looks like you might need to modify the command/script for renewing the certs because it’s still using dummy/example data.

7

I suspected IPv6 initially because a very common issue on the forum when someone has an AAAA record in DNS, but their server is not properly configured to reply to IPv6 requests. Let’s Encrypt will check the IPv6 address first, and can fail there. A change was recently made no Let’s Encrypt that is supposed to make it check IPv4 if unable to connect over IPv6, but there are cases where it won’t move on and jest fail out with this IPv6 failure.

8

I replaced the domain names with example.com

9

So are you saying set up a AAAA record?

10

Adding an AAAA record is unlikely to help. That particular problem is generally about people who have one but whose AAAA record points to a non-working IPv6 address.

11

Can you let us know the domain name? Feel free to private message if you’d like. Have you 100% confirmed that if you go to your-domain.com/.well-known/acme-challenge/ that it displays the response correctly?

12

removed (the answer is below)

13

Hi @kc1,

You need to fix your redirection, you forgot to add // to https:

return 301 https://$server_name$request_uri;

This is causing a wrong redirection appending the url once and again till get the error HTTP/1.1 414 Request-URI Too Large.

Cheers,
sahsanu

15

Hi @nschirmer,

The challenge is deleted by the certbot client so it is normal to receive a 404 error, that is not the problem, as I said, the problem is a wrong redirection reaching the http site (as Let's Encrypt does).

The output is long so you can check what I mean in this output Wrong redirection · GitHub

Cheers,
sahsanu

16

Got it. Sorry, I use a more manual method rather than having certbot create and delete the challenges, so that part got me.

Thanks for chiming in, and hopefully adding the double forward slash helps resolve this for him!

1 Like
17

Thank you @sahsanu . You’ve solved it. Thanks everyone for your help!

18

@nschirmer, could I ask you do anonymize the site name in this post. (It won’t change the answer)

19

Sure thing! Removed. Note that it still exists in @sahsanu’s gist post, just need that removed too. :slight_smile:

20

A post was split to a new topic: Webroot renewal failure with Certbot

21

@kc1, @nschirmer I’ve edited the gist link and changed real domain by example.com.