Certbot renewal fails on apache and ubuntu 16.04

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: datacolaboratory.com

I ran this command:

sudo certbot renew --dry-run

It produced this output:
Attempting to renew cert (datacolaboratory.com) from /etc/letsencrypt/renewal/datacolaboratory.com.conf produced an unexpected error: Failed authorization procedure. www.datacolaboratory.com (http-01): urn:ietf:params:acme:error:serverInternal :: The server experienced an internal error :: Remote PerformValidation RPCs failed, datacolaboratory.com (http-01): urn:ietf:params:acme:error:serverInternal :: The server experienced an internal error :: Remote PerformValidation RPCs failed.

My web server is (include version): Apache 2.4.18 (built: 2018-06-07T19:43:03)

The operating system my web server runs on is (include version): Ubuntu 16.04.5 LTS (xenial)

My hosting provider, if applicable, is: My domain is parked through domains.google.com, but I host my site (DNS is from google).

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

I had run certbot renew previously a few months back and it had run fine (and it is in crontab). Now that the certificate is close to expiration, the crontab job is not working, and when I try to do it manually, the above error shows up for the dry-run. When I try

$: sudo certbot renew

the following message shows up:
Failed authorization procedure. datacolaboratory.com (tls-sni-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Timeout after connect (your server may be slow or overloaded), www.datacolaboratory.com (tls-sni-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Timeout after connect (your server may be slow or overloaded)

I tried with https://acme-v02.api.letsencrypt.org/directory as the server, but no difference.

I have looked through the various answers provided to similar questions on this site, but none of them seem to address what I am running into. Bit stuck in trying to figure out how to troubleshoot further.

--dry-run uses the staging environment, which currently makes several simultaneous requests from different locations. If some of the secondary requests fail, it can eat the real error message and say that instead.

Note also that, due to how the TLS-SNI-01 validation type is being phased out, the staging environment happens to be using HTTP-01 for your sites.

Beyond that semi-useful background, I dunno.

I notice that your site redirects HTTP to HTTPS (which is fine) but HTTPS requests seem to be a little slow. Maybe the server is overloaded? And answering multiple simultaneous requests from Let's Encrypt takes too long?

Good point. Let me try rebooting my server and see if it affects things. How can I get around the TLS-SNI-01 validation type problem? I also noticed the mention of IPv4 vs IPv6 connected with this type of error message, but that appears to be a red herring in my case (since I have not enabled IPv6).

Please show:
/etc/letsencrypt/renewal/{your.domain.name}.conf

This is the conf file:

renew_before_expiry = 30 days

version = 0.22.2

archive_dir = /etc/letsencrypt/archive/datacolaboratory.com

cert = /etc/letsencrypt/live/datacolaboratory.com/cert.pem

privkey = /etc/letsencrypt/live/datacolaboratory.com/privkey.pem

chain = /etc/letsencrypt/live/datacolaboratory.com/chain.pem

fullchain = /etc/letsencrypt/live/datacolaboratory.com/fullchain.pem

Options used in the renewal process

[renewalparams]

account = long alphanumeric stuff

authenticator = apache

installer = apache

There is nothing in the conf file to specify which auth method to useā€¦
Did the reboot correct the problem?
If not, try forcing http by adding:
--preferred-challenges http
or
--preferred-challenges http-01

(see: https://certbot.eff.org/docs/using.html)
(search for: preferred-challenges)

1 Like

Hi,

Forcing to http worked. The reboot did not change anything, but using the preferred challenge updated the cert successfully. I guess I should put that preferred challenge in my cron job too?

Thanks for the help!!

Recheck the conf file for possible preference update:
/etc/letsencrypt/renewal/{your.domain.name}.conf

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