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:




Acme mailing list

Reply via email to