The future of Nginx: Getting back to our open source roots

Re:The future of Nginx: Getting back to our open source roots by Avamander on Wednesday August 24, 2022 @10:27AM (#32579898)

In its most simple form, it works as follows.

/etc/nginx/letsencrypt.conf:

    location /.well-known/acme-challenge {
        default_type "text/plain";
        try_files    $uri $uri/ =404;
        root /tmp/letsencrypt-auto;
    }

/etc/nginx/sites-enabled/default:

    server {
        [...]

        include letsencrypt.conf;

        [...]
    }

Reload nginx.

Invoke certbot for the new domain once with:

    certbot certonly --webroot -w /tmp/letsencrypt-auto/ [--must-staple] -d example.com

[ Parent | on HN ]

Re:The future of Nginx: Getting back to our open source roots by braiam on Wednesday August 24, 2022 @11:07AM (#32580420)

Wait, how does that makes nginx use the certificates? For me it doesn't have any cerbot/letsencrytpt specific configuration as I use DNS-01. I just point ssl_certificate and ssl_certificate_key to the correct path where cerbot saves the certificates and be done with it.

[ Parent | on HN ]

Re:The future of Nginx: Getting back to our open source roots by Avamander on Wednesday August 24, 2022 @11:29AM (#32580700)

Making use is easy as well, like you described. Just a matter of specifying ssl_certificate(_key) path. It doesn't support variables so it can't be based on the server block's domain/variables unfortunately.

DNS challenges are a bit more seamless, but I personally don't like giving access to entire zones to a single machine. Like most DNS APIs force you to.

[ Parent | on HN ]