On Thu, Oct 13, 2016 at 1:10 PM Alan Doherty <i...@alandoherty.net> 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:
> 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