Certbot fails renewal

Help
1

There is apparently a bug in the certbot script. I have been hosting several http only web pages for years and today I decided to try to get https working. I ran "sudo certbot --apache" then answered a few questions and it exited leaving my website working just fine with https now. That part seemed to go very smoothly. However, when I tried to do a dry run on the renewal, I get several errors indicating a failure. The renewal script seems to be looking for a non-existant hidden folder in the web folders. In addition, it seems to be trying to access the folder with http instead of https - http is redirected to https so apache returns "301 Moved Permanently". I have not modified any portion of the apache scripts since certbot modified them.

So certbot made the server work with ssl seemingly ok, but either it did not configure things correctly for the renewal or the renewal script isn't working right. If there is something about my server that made it unhappy, it didn't say.

Below is the other info requested.....

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. https://crt.sh/?q=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:
dombird.org et al

I ran this command:
certbot renew --dry-run -v

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/dombird.org.conf

Cannot extract OCSP URI from /etc/letsencrypt/archive/dombird.org/cert1.pem
Certificate not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator apache, Installer apache
Simulating renewal of an existing certificate for dombird.org and 5 more domains
Performing the following challenges:
http-01 challenge for dombird.org
http-01 challenge for galliform.com
http-01 challenge for irontonfurnaces.com
http-01 challenge for www.dombird.org
http-01 challenge for www.galliform.com
http-01 challenge for www.irontonfurnaces.com
Waiting for verification...
Challenge failed for domain dombird.org
Challenge failed for domain irontonfurnaces.com
Challenge failed for domain www.dombird.org
Challenge failed for domain www.irontonfurnaces.com
http-01 challenge for dombird.org
http-01 challenge for irontonfurnaces.com
http-01 challenge for www.dombird.org
http-01 challenge for www.irontonfurnaces.com

Certbot failed to authenticate some domains (authenticator: apache). The Certificate Authority reported these problems:
Domain: dombird.org
Type: connection
Detail: During secondary validation: 76.137.25.32: Fetching http://dombird.org/.well-known/acme-challenge/E9s8QYKXtKSui1ga2B0QsZ9D-aitAWRWdXAQPcCtORc: Connection refused

Domain: irontonfurnaces.com
Type: connection
Detail: During secondary validation: 76.137.25.32: Fetching http://irontonfurnaces.com/.well-known/acme-challenge/2E7AvUlqbhfv-Ft4K5RGZyz6hUIhSwY-bqOHlkYdNKo: Connection refused

Domain: www.dombird.org
Type: connection
Detail: During secondary validation: 76.137.25.32: Fetching http://www.dombird.org/.well-known/acme-challenge/SCYq8k5ePsR2hgmJiqXaZtY3ST-4j_NHUyh6YQvcLos: Connection refused

Domain: www.irontonfurnaces.com
Type: connection
Detail: 76.137.25.32: Fetching http://www.irontonfurnaces.com/.well-known/acme-challenge/P_g9X2R_SoZMo-s7a-v8iHxfaxHxZKM_WuDFq-ykraI: Connection refused

Hint: The Certificate Authority failed to verify the temporary Apache configuration changes made by Certbot. Ensure that the listed domains point to this Apache server and that it is accessible from the internet.

Cleaning up challenges
Failed to renew certificate dombird.org with error: Some challenges have failed.

All simulated renewals failed. The following certificates could not be renewed:
/etc/letsencrypt/live/dombird.org/fullchain.pem (failure)

1 renew failure(s), 0 parse failure(s)
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

My web server is (include version):
Server version: Apache/2.4.63 (Ubuntu)
Server built: 2025-07-14T15:12:31

The operating system my web server runs on is (include version):
Linux asterisk 6.12.15-production+truenas #1 SMP PREEMPT_DYNAMIC Mon Sep 8 18:50:34 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

My hosting provider, if applicable, is:
self

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

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

2

That is outdated.

To me, it seems like, you may have GEO-location blocking in place.
OR some kind of rate limiting...

4 Likes
3

NOTE:

  • Certificate renewals are processed by LE production systems
  • dry-run simulations are processed by LE staging systems

They are likely NOT is the same data center(s)/country(ies)

3 Likes
4

This is the version that I got with the command:
sudo apt install certbot python3-certbot-apache
How do I get the latest version?

5

I forgot to mention that this server is running in a trueNas container. Considering all the problems I've had with the container, I half expect the problem to be "Its because you are running it in a container".

6

The Let's Encrypt staging environment is currently disrupted.

4 Likes
7

Those installation instructions may be outdated...
See: https://certbot.org for the latest

4 Likes
8

I waited until the status was all green (wrong url for the status page) and the response was the same - Challenge failed - connection refused.

Here is a snippet showing the response:


Performing the following challenges:
http-01 challenge for dombird.org
http-01 challenge for galliform.com
http-01 challenge for irontonfurnaces.com
http-01 challenge for www.dombird.org
http-01 challenge for www.galliform.com
http-01 challenge for www.irontonfurnaces.com
Waiting for verification...
Challenge failed for domain dombird.org
Challenge failed for domain irontonfurnaces.com
Challenge failed for domain www.dombird.org
Challenge failed for domain www.irontonfurnaces.com
http-01 challenge for dombird.org
http-01 challenge for irontonfurnaces.com
http-01 challenge for www.dombird.org
http-01 challenge for www.irontonfurnaces.com

Notice that there is no mention of galliform.com in the error list. But at the bottom is says "All simulated renewals failed."

10

Snippets often hide essential information. Please show all of the console output in the future.

The meaning of "All simulated renewals" refers to a certificate and not each of the domain names within it. Above is from your first post. It refers to your cert with the name dombird.org. See your certs using: sudo certbot certificates

Your first post shows the above kinds of errors.

One of them mentions "Secondary" but the other does not. It looks like you have a firewall that is blocking access to port 80 by IP address or perhaps geographic region. And, may also be blocking based on overall volume of requests like protecting from DoS attacks and set very strict.

There are problems accessing your system from many places around the globe. These are tests requesting your "home" page so are not related to Let's Encrypt. But, LE is failing for the same reason so the same cause likely affects all requests.
dombird: Check website performance and response : Check host - online website monitoring
irontonfurnaces: Check website performance and response : Check host - online website monitoring

ALSO,
Your galliform.com and its www subdomain have both IPv4 and IPv6 addresses. Both IPv4 and IPv6 HTTP requests redirect to HTTPS. But, oddly, an HTTPS IPv6 request fails with "connection refused" whereas the IPv4 works. None of your other domains use IPv6 so this is should be reviewed but is not the main problem.

3 Likes
11

Thanks! That was very helpful. Here is the latest run:

certbot renew --dry-run -v
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/dombird.org.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cannot extract OCSP URI from /etc/letsencrypt/archive/dombird.org/cert1.pem
Certificate not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator apache, Installer apache
Simulating renewal of an existing certificate for dombird.org and 5 more domains
Performing the following challenges:
http-01 challenge for dombird.org
http-01 challenge for galliform.com
http-01 challenge for irontonfurnaces.com
http-01 challenge for www.dombird.org
http-01 challenge for www.galliform.com
http-01 challenge for www.irontonfurnaces.com
Waiting for verification...
Cleaning up challenges

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations, all simulated renewals succeeded: 
  /etc/letsencrypt/live/dombird.org/fullchain.pem (success)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

It looks a little better. The "Cannot extract OCSP URI from /etc/letsencrypt/archive/dombird.org/cert1.pem" error must not be that serious.

Anyhow, the firewall has rate limits set on both ports. I thought it was high enough, but I'm guessing that certbot must be pounding it for some reason. I temporarily disabled the rate limits and the above run is what I got. Maybe certbot should be more vocal about that. Because the real renew has to run with a cron job, I'll need to play with the limits until I find a happy medium. Based on what I've read, I believe that LE will send me an email on renewal to let me know if there was a problem.

Regarding ipv6, yes, there is a problem. Part of it is with the registrar. Just getting it to resolve at all has been a huge problem. IPv6 still is not supported universally. There are also huge security issues with IPv6 that don't exist with IPv4. Like IPv6 packets just skip over NAT like it wasn't even there. Since each device has its own IPv6 address, with a misconfigured firewall, a hacker could log directly into your local device (printer, refrigerator, TV, etc), cause trouble, steal data, whatever. I haven't had time to work on the IPv6 issue in a while, but I may have blocked all IPv6 traffic for security reasons. I'll eventually get back to it.

Thanks again for the help solving the LE issue.

1 Like
12

It is not. Let's Encrypt quit using OCSP in favor of CRL. I am pretty sure newer versions of Certbot would not warn about that.

It is not technically Certbot that is "pounding it". Certbot is the ACME Client and makes the cert request. Let's Encrypt is the ACME Server and it is the one sending requests to your domain to ensure you control it.

For an HTTP Challenge (that you are using) it sends a challenge from each of its validation centers. LE currently has 5 such centers around the world. A challenge is made from each center for each domain name in the cert. LE may change the number of centers without notice so don't build your solution around that specific detail.

If your firewall has an API maybe use the Certbot --pre-hook and --post-hook to increase the limit during a cert request?

It used to but not since last summer. See: Expiration Notification Service Has Ended - Let's Encrypt

Then you should also remove the AAAA record. Let's Encrypt will favor IPv6 when an AAAA record is present. It will fallback and try IPv4 but only for specific timeouts and only for the initial challenge not any redirection. See: IPv6 Support - Let's Encrypt

Other systems using "Happy Eyeballs" or similar will also be affected by a non-working IPv6 AAAA record IP. If nothing else it causes useless traffic.

3 Likes
13

Typically routers have a stateful firewall to prevent inbound connections that uses similar connection tracking to what's used in a NAT, however without the port number or IP address changing.

This does mean that you then have to explicitly allow incoming connections to public services similar to setting up port forwarding.

Of course you don't have to setup IPv6 (for the moment), just thought I'd give some pointers for securing an IPv6 network.

3 Likes