On 12.01.18 04:06, Roland Bracewell Shoemaker wrote: > I'm actually going to roll back my thoughts on the SNI value. Thinking > about this more I think it does actually make sense to revert to using > the actual host name here. > > In the initial design of the TLS-SNI challenge the XXX.acme.invalid > value was used as a way to allow servers to dynamically serve both > regular and validation traffic. Since we would be using ALPN here we no > longer need a special SNI value in order to differentiate validation > traffic from regular traffic so this token value is no longer needed.
One minor advantage of keeping the current acme.invalid scheme is that it allows people to use SNI-based routing. Web servers like HAProxy allow you to proxy requests (on the TCP layer) based on the SNI value, so you could match "*.acme.invalid" and forward it to a validation server that supports the new challenge and the ALPN ACME protocol, even if the web server itself doesn't. If we use the "real" identifier for SNI, we'd limit that option to web servers that natively support the ALPN value for ACME and can route based on it. Not sure how common this kind of setup is, if it's just a small subset of HAProxy deployments it'd probably not have much of an impact. Patrick [1]: https://www.cloudoptimizedsmb.com/articles/20160409-00/using-haproxy-to-split-letsencrypt-acme-challenges-from-regular-traffic _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
