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:c...@letsencrypt.org>c...@letsencrypt.org> 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:t...@seoss.co.uk>t...@seoss.co.uk> 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:Acme@ietf.org>Acme@ietf.org
>https://www.ietf.org/mailman/listinfo/acme
>
>
>_______________________________________________
>Acme mailing list
><mailto:Acme@ietf.org>Acme@ietf.org
>https://www.ietf.org/mailman/listinfo/acme
>
>_______________________________________________
>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

Reply via email to