Certbot + Nginx setup with an app using Nginx as reverse proxy: is it okay?

[mcdado]

Preamble

I’m trying to understand how to Nginx plugin works and if I need to do anything about the current setup. I have already setup a Debian 10 (buster) server, and plan to install a Node.js app on it.

Setup

Firstly though, I set up Nginx and Certbot, so I have a functioning certificate for my server.
I did so like this: certbot run --nginx -d sub.example.com.

Certbot was helpful enough to add the needed directives to the default site configuration (/etc/nginx/sites-available/default) but I moved all the edits to a separate configuration in sites-available, called certbot for now, and linked it in sites-enabled.

The actual question

From my understanding, with this setup Certbot auto-configures Nginx to serve the HTTP-01 challenge in .well-known, but this means that it needs to take over the http/https ports which should be serving the app (through server directives that I still need to write in the sites-available config file). So, setting up a web server which uses Nginx as reverse proxy does it mean that during the challenge for renewal the app has a downtime? I don’t mean during the post_hook which reloads Nginx, I mean when the certbot client is performing http01 challenge.

Moreover, I tried deleting the symlink from sites-enabled and reloaded nginx, but the challenge succeeded anyway, how does it do the Nginx setup? Does it spawn an ad-hoc nginx with a custom configuration?

[orangepizza]

It mostly keeps backend, just /well_known directory in http version redirected to certbot. So no downtime

[mcdado]

Thanks. I took the time to inspect the certbot-nginx code on Github and run certbot renew --dry--run -vvv to see exactly what happens.

Certbot creates a temporary config file for Nginx with the necessary instructions to answer the challenge, gracefully reloads nginx with -c config_file_path -s reload which basically adds the instructions without significant downtime. I didn’t get into anymore details but I imagine at the end it restores all the original config files and reloads nginx again without the -c parameter.

[mnordhoff]

Carving out the validation path and reloading Nginx should not cause any downtime.

[mcdado]

Correct, according to Nginx: https://www.nginx.com/faq/how-does-zero-downtime-configuration-testingreload-in-nginx-plus-work/

I had read on some Stack Overflow that somebody experienced some downtime so I didn’t want to just write no downtime, but maybe there was something wrong with their setup.