--dry-run fails while live renewal succeeds

My domain is: qse.magnesia.de

I ran this command: sudo certbot -v --dry-run renew and sudo certbot -v --dry-run --force-renew renew

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/qse.magnesia.de.conf

Certificate not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator nginx, Installer nginx
Running pre-hook command: /etc/letsencrypt/renewal-hooks/pre/ports_oeffnen.sh
Simulating renewal of an existing certificate for qse.magnesia.de
Performing the following challenges:
http-01 challenge for qse.magnesia.de
Waiting for verification...
^@Challenge failed for domain qse.magnesia.de
http-01 challenge for qse.magnesia.de

Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
Domain: qse.magnesia.de
Type: connection
Detail: Fetching http://qse.magnesia.de/.well-known/acme-challenge/E1nmEieytsZigjLQhn1Eb_h8Dq-JijD3hsW7L5sLK6w: Timeout during connect (likely firewall problem)

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

Cleaning up challenges
Failed to renew certificate qse.magnesia.de with error: Some challenges have failed.

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

Running post-hook command: /etc/letsencrypt/renewal-hooks/post/ports_schliessen.sh
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): nginx/1.18.0 (Ubuntu)

The operating system my web server runs on is (include version): Ubuntu 22.10

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: certbot 1.21.0

When I run sudo certbot -v --force-renew renew it succeeds.

It's probablyalmost certainly re-using a previously valid authorization, something --dry-run won't do.

Please don't force renew any new production certificates and try to fix your problem with the --dry-run.


Please stop using --force-renewal. It is redundant with --dry-run and doesn't force a bypass of problems without --dry-run. It often leads people to get rate limited which you now are. You already got 5 certs with that name in the past week

As to your timeout problem, this is probably because your pre-hook isn't opening the port correctly. Right now I don't see port 80 or port 443 open. Should at least one of them be?

I also see you are getting certs from the Staging system so the --dry-run must be working sometimes


Which authorisation are you referring to?

I am sorry for firing so many renewal requests. I am quite new to Let's Encrypt and certbot.

We have neither port 80 nor 443 open on that server. So I was testing a script to open them just for the renewal. I wasn't aware of the --dry-run option then.

Later I came across the Certbot hooks. So I created a pre-hook to open the ports which works with a live-renewal (with --force-renewal as our certificates are quite new).

However --dry-run fails with the same pre-hook. I could verify that the ports were opened during the dry-run.

So certs from the Staging system are just issued for --dry-run requests?

Did they stay open to handle multiple inbound HTTP requests from various locations? Because several Let's Encrypt servers will make requests during it multi-perspective validation.

Can you check your server access logs to see how many requests arrived for --dry-run? Could you compare that to your firewall log?

Yes, and when using --test-cert option. For --dry-run the staging cert is discarded but Let's Encrypt issued it which is why it appears in the public logs.


I guess that there could be a slight delay between executing the commands to open the HTTP and HTTPS ports and network rules on the firewall actually been changed.

When I opened the ports manually --dry-run always succeeded. Relying just upon the Pre-Hook script it failed sometimes.

So I added a sleep delay in the Pre-Hook script. Which works fine so far.

Thanks all for your help and for pointing me to the right direction.opened.order I found the problem.


With "authorization" we mean the combination of an account and a successfully validated hostname, sometimes abbreviated with "authz". Let's Encrypt caches valid authorizations for 30 days. With --dry-run Certbot actively deactivates these valid authz so that the validation server always tries to do a validation. But because --dry-run also automatically selects the staging server, any valid authz on the production server is left alone. Thus --dry-run could fail, while without --dry-run it could succeed.


Thanks, Osiris!


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