I was hoping someone could satisfy my curiosity about how certbot and nginx interact during renewal time.
On my Linux host, I set up certbot and the certbot-nginx plugin. I had some regular nginx site definitions set up in /etc/nginx/conf.d, and when registering certs the certbot-nginx plugin added the TLS information to these individual nginx conf files for my various sites.
To renew, I have the following in a systemd service triggered once a day :
/bin/certbot renew --non-interactive --agree-tos --no-self-upgrade --post-hook "systemctl reload nginx"
Looking at the systemd logs with journalctl, I can see the certs being updated when appropriate.
It works, but it's bugging me that I can't find anything in my config that tells nginx to let requests through on '.well-known/acme-challenge' for any of my domains. It's not in any of my nginx config files. I'm just wondering how certbot is able to offer up the token on that path. I've grepped chunks of the filesystem for 'well-known' and 'acme-challenge', but nothing turned up. The only 'root' directives in my site nginx config files point to their respective static sites. There's nothing but the default 'It Works' site in /usr/share/nginx/html.
Does certbot spin up a server of its own? I was dubious as I didn't think it would be able to bind to port 80 at the same time as nginx.
certbot's nginx plugin, when it needs to do a ACME challenge via http, will modify nginx's configuration. The config parser they wrote is capable of reverting the challenge configuration, as it is cleaned up you won't see it persist.
Just the nginx plugin of certbot is a couple thousand lines of code, to implement the parser, authenticator, installer, and deal with real world complications. How much to care about how it works is up to you. To some people, a fancy program automatically fixing their https configuration is a feature, to others a bug.
External links referenced by this document: