Hector Martin

The closest thing to the previous hands-off behavior I can think of is using iptables to send port 80 to some other port, and deploying an nginx config that passes that through to port 80 on self except for the well-known ACME paths. But ugh.

I guess a less ugly method would be to have the default vhost serve the ACME challenges and then having an include to add that functionality in every additional port 80 vhost. Still ugh.

That’s what I do: # Within each site config server block: include snippets/letsencrypt.conf; # letsencrypt.conf: location ~ .well-known/acme-challenge/ { root /var/www/letsencrypt; default_type text/plain; }

Yes, this is the plan. But the previous config required zero additional config stanzas (other than the cert itself).

I guess I just don’t see it as a hindrance as you do. I’ve been using letsencrypt this way all along, for every site and nginx server I host

It's not a huge deal but it's not as nice and magical as TLS-SNI-01 which Just Worked.

Ended up requiring some more effort to handle top-level redirects, allow/deny and similar. rewrite ^(/.well-known/acme-challenge/.*) $1 break; location ^~ /.well-known/acme-challenge/ { root /var/www/acme; allow all; default_type text/plain; break; }

certbot configs: for i in *; do echo $i; sed -i s/certbot-external:external/webroot/g $i; (echo webroot_path = /var/www/acme; echo '[[webroot_map]]'; openssl x509 -in ../live/${i%%.conf}/cert.pem -text|tr , '\n'|grep DNS|sed -re 's, *DNS:(.*),\1 = /var/www/acme,') >>$i ; done