Re: [Acme] Fixing the TLS-SNI challenge type

[Niklas Keller <[e-mail]>]

I'm not sure, but I guess a certificate / key selection based on the ALPN
value needs integrated support in webservers then. Currently these can be
configured with a simple additional virtual host. I'm pretty sure
application servers written in PHP wouldn't be able to do that currently.
They're probably pretty rare compared to a traditional PHP deployment, but
other languages might be similarly affected.

How about extending the HTTP challenge instead? Validation via HTTP+TLS on
port 443 has been disabled due to shared hosting, which might be configured
correctly on port 80, but choose the first virtual host in case of port
443, given not all hosts have a TLS configuration. If we mandate that port
80 must be tried first and result in connection refused / TCP connect
timeout (might be unbound port or DROP / REJECT in a firewall, an HTTP
timeout doesn't count) before validating via port 443, couldn't that work?
I think TLS-SNI mainly makes sense where port 80 is closed and not required
for redirects anyway, e.g. APIs like api.github.com.

Regards, Niklas