At 17:39 13/10/2016 Thursday, Ben Irving wrote: >Hello, > >I have ran into a very similar use case. In my case I'm using Haproxy to route >tcp requests based on the server name indication to upstream web servers where >the TLS request is terminated. The ACME client is also running on these >upstream web servers. I'm forced to use HTTP-01 challenges and am forced to >open up port 80 as well on these upstream servers, which I don't want to do. I >don't expect the protocol to solve my particular use case, but I'm also >curious as to why acme.invalid was used as the suffix for all TLS-SNI based >challenges?
you shouldnt have to open port 80 to upstreams (assuming on the haproxy you do the normal http redirecting on port 80 aka requests for http://whatever get a 301 redirect to https://same-domain/same-path as the http-01 challenge will happily follow redirects and thus find/connect to https://whatever-domain/acme-specific-url >- Ben > > >On Thu, Oct 13, 2016 at 8:00 AM Daniel McCarney ><<mailto:[email protected]>[email protected]> wrote: >Hi Tim, > >Thanks for sharing your thoughts. This was the first time I've heard about this >sort of SNI multiplexing middleware in the context of IPv6 hosting. > >I'm newer to the list/draft process but I suspect your idea of using >"<http://x.y.token.acme.client2-example.com>x.y.token.acme.client2-example.com" > to support the SNI multiplexing decision >will run counter to the intent behind using the ".acme.invalid" suffix as >described in the current draft. Perhaps someone with more historical context >can >help clarify why that particular suffix strategy was selected. > >It would help me understand your feedback better if you could speak to why it >doesn't make more sense for users of this sort of middleware to favour the >HTTP-01 or DNS-01 challenge type. My own opinion leans towards thinking that >using a more appropriate challenge type is preferred to trying to address TLS >middleware in the context of the TLS-SNI-02 challenge design. This class of >middleware can introduce all sorts of complication that might end up >significantly complicating the challenge design. > >- Daniel/cpu > > >On Wed, Oct 12, 2016 at 6:45 AM, Tim Small ><<mailto:[email protected]>[email protected]> wrote: >Hello, > >Having read draft-ietf-acme-acme-02, and made a number of early >deployments using the tls-sni-01 mechanism, I thought I'd highlight what >I perceive to be a possible shortcoming with the tls-sni-02 draft. > >It's becoming more wide-spread (as a result of IPv4 exhaustion) to >deploy TLS SNI "switches" to provide IPv4 connectivity to autonomously >managed web servers. > >The typical deployment pattern is that a web server is assigned a >publicly accessible IPv6 address only - this can be used for direct >management and direct IPv6 https requests etc. The TLS request are >terminated on the web server itself. > >The customer is also informed of an IPv4 addresses to be used for web >access by IPv4-only clients, and asked to provide a list of FQDNs which >they will serve. IPv4 https requests are answered by proxy software, >which direct the IPv4 https request to the correct web server's IPv6 >address (or an RFC-1918 IPv4 address etc.) based on SNI. > >e.g. this haproxy example configuration fragment: > >use-server customer1-staging if { req.ssl_sni -m beg ><http://staging.customer1-example.com>staging.customer1-example.com } >use-server customer2-live if { req.ssl_sni -m beg ><http://staging.customer2-example.com>staging.customer2-example.com } > > >I believe this will become increasingly common-place during the >transition to IPv6, and the current form of tls-sni-02 makes it hard to >use in this sort of environment. > >The problem comes when using tls-sni-02 ACME challenges: > >"The client MUST ensure that the certificate is served to TLS >connections specifying a Server Name Indication (SNI) value of SAN A." > >i.e. the SNI string which the proxy sees during the challenge is always >"SAN A" (x.y.token.acme.invalid), for any server for which it acts as >the "https switch" for. > >... so the proxy has no way of knowing which server the challenge >request should be directed to. Some mechanism by which the proxy can >direct the request would be useful. > >One which may provide an easy route for the service providers offering >this sort of setup (many would require no changes to their existing >configuration at all) would be to append the FQDN in the TLS SNI value >e.g. ><http://x.y.token.acme.client2-example.com>x.y.token.acme.client2-example.com > >The client in question may have limited or no influence on the >configuration of the SNI proxy, so the more straight-forward the proxy >configuration, the-better. > >For another example of a similar use-case with the same issue: > ><https://scriptthe.net/2015/02/08/pass-through-ssl-with-haproxy/>https://scriptthe.net/2015/02/08/pass-through-ssl-with-haproxy/ > >HTH, > >Tim. > >_______________________________________________ >Acme mailing list ><mailto:[email protected]>[email protected] >https://www.ietf.org/mailman/listinfo/acme > > >_______________________________________________ >Acme mailing list ><mailto:[email protected]>[email protected] >https://www.ietf.org/mailman/listinfo/acme > >_______________________________________________ >Acme mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
