mdhardeman

I concur in full with your commentary here.

LetsEncrypt, through thoughtful planning and action -- even when it was inconvenient for them -- has established themselves as a shining beacon of best practice.

For better or worse, when you become the best practice example, you are held by the world -- and especially by your peers -- to a higher standard.

I can not imagine how they would see a return to production status of TLS-SNI-01 as anything other than painting a target on themselves for their various detractors to take aim at.

It is no secret that numerous other parties in the CA space would love to see them slip and fall.

I think the only fix is to create TLS-SNI-03 in which the only dnsName component in the self-signed certificate is a well known child of the domain label to be validated.

Validating www.abc.com, SNI and dnsName is well-known-acme-pki.www.abc.com and the certificate should have some other parameter stuffed with a challenge response that is defined to be a challenge response calculated over the inputs of a random token provided to the requestor by the CA and the account key of the requestor.

If it's something like that, the fix would be to define a tls-sni-03 with a couple changes:

The SNI name indication from the validation MUST be a child element desired certificate domain label.

(If I want a cert for a.com, the SNI indication in the TLS-SNI-03 would need to be something like obvious-acme-challenge.a.com)

Further, the self-signed cerfificate needs to have the SAN dnsName as in the SNI -- AND ALSO -- another authentication token signed by the account key stuffed into the certificate in some other certificate field.

I can totally believe that may exist too.

After all, for the CDN / Hosting company, what's the real risk?

It wouldn't shock me if lots of infrastructure lets you board a new and novel host label that hasn't already been boarded and starts letting you configure things like a custom TLS certificate to be associated with that label.

As long as they watch out for uniqueness, what's the risk to the CDN? That a config context gets created for a DNS label that isn't yet pointed there? It's not an obvious risk from the CDN's perspective. Even for an invalid domain.

"Oh, sad, I just wasted mere kilobytes of storage on a configuration for a domain that you're never going to actually be able to get into the DNS and point to me?" That sounds kind of low cost, from the CDN's perspective.

I just read the details of the tls-sni-01 challenge again.

I can certainly see a problem. With respect to the final validation stage, where the validator is communicating with the TLS endpoint, all the information needed to satisfy the validator is presented IN the SNI request data.

It looks like anyone could request a tls-sni-01 validation with any account key, for a host that they new would resolve to a TLS server infrastructure with a certain behavior and in turn be able to get the certificate issued.

The qualifying behavior would be a TLS server infrastructure which has some sort of opportunistic generation of a self-sign certificate for an unrecognized SNI name, such that the just-in-time minted certificate would have a single SAN dnsName being that exact value requested in the SNI. Unlike the other challenges where the final validating query from the VA does NOT contain the "answer" needed, it would appear that the in the final pass of the TLS-SNI-01 protocol exchange, the final "answer" is indeed in the request.

You know, I'm trying to recall the details, but I'm pretty sure I came across a consumer router platform once that, until and unless administratively configured with a certificate, would keep opportunistically recreating certificates to match the SNI name. This was to make the only validation failure be "signed by an untrusted..." instead of "name mismatch", etc, etc.... I wonder if a critical mass of things like that has arisen?