Failure during auto renew

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

@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.

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.

I replaced the domain names with example.com

So are you saying set up a AAAA record?

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.

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?

removed (the answer is below)

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

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

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

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

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

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

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

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

Deleted my comment since you can easily view edit history. :slight_smile:

One note, just because some people believe that relying on obscurity is effective security, your domain name will still appear in the public certificate transparency logs every time you issue a certificate. If you’re relying on this domain not being public, you should reevaluate some design choices.

I realize it’s exceedingly likely that you are not of this mindset, but it’s worth noting just in case.

I still want to post an item about reasons why forum users would benefit by sharing their domain names, but I'm still waiting for a really useful DNS testing tool, as described in the thread

(because I wanted to create a norm that people who won't share their domain names should at least take a set of steps to eliminate likely misconfigurations as the source of their problems—but we might need slightly better tools to hepl people to do that)

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