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


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.


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?

1 Like

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


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.

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

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.

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