> > I agree this approach will limit compatible TLS servers but luckily > HAProxy should be fully compatible.
Alas, there's nothing like hitting send on a message to a mailing list to make you think a little bit harder. I overlooked the fact that it doesn't seem possible to select the certificate based on the ALPN, just the backend. That's not really the primary difficulty at hand. I suspect matching the request to the `bind` with the correct alpn is still going to be problematic if the server needs to respond to requests for the real identifier with both a certificate and a challenge response certificate. I would be happy to be corrected :-) On Fri, Jan 19, 2018 at 9:43 AM, Daniel McCarney <[email protected]> wrote: > 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 <[email protected]> > 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/acme >> > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
