Issue with TLS-ALPN-01 Validation Method

Head of Let’s Encrypt here. This is a compliance issue, there is no security or validation integrity risk.

If you actually read the EV certificate, you might be able to reasonably tie what you learned to a DNS name, which is what really matters for the circumstances where you're using TLS, as we'll see in a minute:

The Certificate can tell you the identity of a legal entity which the CA made some reasonable attempt to verify wanted to set in stone the association between their identity and the DNS names listed (and also a key but don't worry about that). You should examine not only the name of that entity, but also the country or locality in which it claims to exist (this may be a tax haven) and its ID# in that country or locality's records, such as tax records, which may enable you to distinguish it from other entities with similar (or in some cases the same) names. The latter is in a certificate element labelled "serial number" but is the serial number of the subject entity not the certificate's serial number, which today is mostly a large random number of no importance (it is serving as a cryptographic nonce but you don't need to care about that)

Anyway, once you've carefully examined these details, and determined which entity you've got a certificate for, like I said the main value is that it tells you the DNS names associated.

Almost all the software tools you use, such as a web browser don't care about any of that stuff, but they do care about DNS names. So transactions e.g. following an HTTP redirect which are done silently and automatically by the browser, won't care that this is (or is not) a EV certificate at all, but they do check the DNS names on a certificate.

So if you're able to determine from the certificate that mybank.example really is run by My Bank Inc. the bank you've got money in, that's a valid use for EV, but your browser doesn't care whether the HTTPS server it talks to shows it that EV certificate (or any other EV certificate) during HTTPS transactions, only whether the DNS names are right. It would not for example, stop during a 30x redirect and say "Oh! This is a 30x redirect from mybank.example but it didn't present that EV certificate you checked, maybe it's an imposter?" that 30x redirect is fine, the certificate was fine, and you'll never see it at all, it will never be shown to you, your data was transmitted long before you had a chance to have an opinion anyway so who cares.

I can totally understand your frustration. It is way too expensive for certificates and costs have gone off the rails.

Yes, browsers have removed the green trust bar.

Yes, ordinary users have to click on small buttons and manually check against different conventions used by CAs (naming, extensions, OID variants).

However, saying that EV provides no extra security not entirely true. At least if we look outside the end-users of a website.

It is also used for: - High security applications that have to ensure their services are trustworthy - As confidence/trust factors in cyber threat intelligence (if you don't want to get blocked on a false positive, EV is your friend) - In domain name research when trying to establish ownership - In machine learning models as an indicator of verifiable trust - Protects against website copying used in phishing campaigns

I'm focusing on HTTPS here as EV is much more relevant in PKI systems.

EV should be affordable, relevant, have good UX and provide identity security for end-users of browsers, but it is not. Until that changes, most website owners should not buy it.

It is unfortunate. It's required: https://github.com/cabforum/servercert/blob/main/docs/BR.md#...

That's very close to what I'm doing, except I now refuse to touch certbot with a 10-foot pole. Plenty of better, do-one-thing-well, non-paternalistic ACME clients out there as you said.

The fact that there are alternatives, though, doesn't mean that the crappy "official" client isn't doing the LE ecosystem a disservice.