> > 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.
I agree this approach will limit compatible TLS servers but luckily HAProxy should be fully compatible. HAProxy has a "ssl_fc_alpn"[0] layer 5 fetch method that can be referenced in a "use_backend" directive to route based on the negotiated ALPN from the handshake. It looks like the feature has been present since HAProxy version 1.5 which hopefully means most HAProxy deployments will have access to it. As one data-point Ubuntu 16.04 LTS packages HAProxy 1.6.3 and should be able to build a ALPN-based routing solution similar to what was done for SNI. [0] - http://cbonte.github.io/haproxy-dconv/1.8/configuration.html#7.3.4-ssl_fc_alpn On Fri, Jan 12, 2018 at 10:29 AM, Patrick Figel <patrick@figel.email> wrote: > 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 > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
