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