Re: [Acme] Fixing the TLS-SNI challenge type

[Patrick Figel <[e-mail]>]

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