Hector Martin

The recent @letsencrypt shutdown of TLS-SNI-01 validation (due to idiotic hosting providers) is very disappointing. It was by far the most convenient, hands-off, universal validation mechanism. https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188 …

DNS-01 requires making all my DNS zones dynamic, which is a PITA and increases complexity. HTTP-01 requires pre-provisioning site configs and having a mutable webroot. TLS-SNI-01 was great because it didn't clash with actual production configs at all so it always worked.

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