On Thu, Oct 13, 2016 at 1:10 PM Alan Doherty <[email protected]> wrote:
> 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 Maybe I'm misunderstanding, but I don't think there is an ACME client that runs on port 443 for challenge type http-01. The major hurdle here is that I'm running the ACME client upstream. However, since I'm not able to route the TLS-SNI challenges to the correct upstream client, I'm forced to use HTTP-01 and open up port 80. > > > > 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
