New certs work - renewals fail

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., so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command: certbot certonly --apache -d -d --dry-run

It produced this output:
Failed authorization procedure. (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching Connection refused, (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching Connection refused

My web server is (include version): Apache 2.4

The operating system my web server runs on is (include version): AWS Linux 2 (current)

My hosting provider, if applicable, is: Amazon Web Services

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):n/a

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

We’ve just started using Certbot. No problems creating new certs, but now that renewals are due - they are all failing with connection refused errors similar to the message above. I setup this domain as a test. Issued a new cert, allowed certbot to setup all traffic https redirect in the .conf file - works fine. However, when I try a dry run on the renewal - I get the same error I’m getting on all my other certs when I run certbot renew.

I revoked, deleted, and re-installed the cert for this domain - same error.

I ran curl -v for all connections and it appears to be okay.

Any ideas why?

Maybe there are hooks that stop the web server before renewing? You might have set them up if you used Certbot’s standalone plugin in the past.

Can you check or post /var/log/letsencrypt/letsencrypt.log?

Edit: Or perhaps some of Let’s Encrypt’s IP addresses are blocked by a firewall?

Did the initial cert use HTTP-01 auth or TLS-SNI-01 auth?

--dry-run request are now being forced over HTTP.
It seems your system is not allowing HTTP connections.

1 Like

Thanks to all for your help. Turns out it was Fail2ban that was blocking the IP used to renew certs. Not sure what rule triggered it - I have the same rules running on another server and renewing one at a time worked.

I think it was something that happened when I ran the certbot renew command. It renewed the first domain then started blocking on the second.

Hope this helps someone else!


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