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?
- Ben
On Thu, Oct 13, 2016 at 8:00 AM Daniel McCarney <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
> "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 <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
> staging.customer1-example.com }
> use-server customer2-live if { req.ssl_sni -m beg
> 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. 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/
>
> HTH,
>
> Tim.
>
> _______________________________________________
> 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
>
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
