And I see 404 status codes in nginx access.logs and perhaps more notably i see in the error.logs No such file or directory looking for the acme-challenge/<token>.
Which succeeds with The dry run was successful. and in my nginx access logs i see 200 status codes.
I tried to use a minimal virtual host config but i still get the same result - it appears that during dry-run certbot is looking for file but with --debug-challenges the nginx configuration is using the certbot nginx temporary code correctly.
So far i'm able to generate a certificate but not able to renew unless i do so manually and with --debug-challenges. I need automatic renewals to work.
My web server is (include version): nginx 1.24.0
The operating system my web server runs on is: ubuntu 24.04.3
The --nginx option can cause the symptoms you describe if your nginx server takes longer than 1 second to reload. Is it an especially large nginx config or perhaps just slower than usual?
The reason is that after Certbot makes the temp change to your nginx it issues an nginx reload. This is asynchronous so Certbot sleeps, by default, for just 1s. If nginx takes longer than that it won't have the needed temp code active in its config.
To check this try adding a longer sleep with this on your renew --dry-run --cert-name X command
--nginx-sleep-seconds NGINX_SLEEP_SECONDS
Number of seconds to wait for nginx configuration
changes to apply when reloading. (default: 1)
Start with something like 3s if this problem has only started recently. Perhaps even longer sleep if this is a new and large (or slow) nginx system just starting to use Certbot.
If this is the cause there are several ways forward. The most efficient is probably to use --webroot instead but let us know about the sleep and we can talk further.
Yeah, if the reload by the --nginx option didn't complete within 1s the temp changes would not be effective. Then nginx uses the pre-existing server block which (in this case) redirects (per usual).
I think that redirect is a symptom and not a problem
Good. If you have just the one certificate re-run the original command without --dry-run and adding --nginx-sleep-seconds. That will update the renewal config file
sudo certbot certonly --nginx --cert-name bitcastle.lol --nginx-sleep-seconds X
Usually that sleep is only needed for systems with a large number of certs and server blocks. Or some other complex nginx config.
How many Certbot certs do you have? Or plan to have?
The best way forward depends on why you needed the sleep
I would like a solution that can handle as many as necessary without having this failure, it could be anywhere from 10-50.
I wanted to use the nginx authenticator because it automatically adds the SSL configuration to nginx server blocks which is very convenient when adding new certs.
I'm assuming you will recommend using webroot to handle many certs? Are there any drawbacks to switching? What are my options? Can I still use nginx authenticator with some modification?
As long as you set a sleep-seconds long enough it will work. But, over time you may well be unhappy about how long those take and it will be more difficult to change. You should set the sleep-seconds in a cli.ini rather than for each command.
I think larger installs should use --webroot. It takes a bit more to setup initially but is far more efficient and scales very well.
You can even mix --webroot as authenticator with --nginx as installer. Although I personally find that not too useful you might like that it creates the server block for port 443 for you. I think once you've seen a couple of those done you know how to do it and can make your own template.
Most volunteers here will say to avoid using --nginx as authenticator for large installs. It isn't just me
I think you understand some of its workings based on your first post. But, it does this:
Parse nginx conf to locate the port 80 server block
Insert specific code into that server block (a location and a return)
Reload nginx and wait sleep-seconds
Request the cert
Remove the temp changes from nginx server block
Reload nginx and wait sleep-seconds
Webroot just writes a token file to the specified location and requests the cert. You use a --deploy-hook to reload nginx only when it actually gets a fresh cert (so not often). Very efficient.
I can provide a template nginx server block that handles the --webroot location if you wish. Let me know
