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
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.
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.
“Your ideas are intriguing to me, and I wish to subscribe to your newsletter.”
Is there a detailed writeup on this? This sounds great, but I don't want to faff about with it.