[agwa]

> The underscore prefix ensures that the random value cannot collide with an actual domain name that uses the same random value. While the odds of that happening are practically negligible, the validation is still deemed as non-compliant if it does not include the underscore prefix.

That's not the rationale for mandating the underscore prefix. The actual reason is so services that allow users to create DNS records at subdomains (e.g. dynamic DNS services) can block users from registering subdomains starting with an underscore. It serves the same purpose that /.well-known does.

For example, if an attacker requests a certificate for dyndns.example and DigiCert gives them a record without an underscore prefix like da39a3ee5e6b4b0d3255bfef95601890afd80709.dyndns.example, they can register that subdomain with the dynamic DNS provider, publish the required record, and get the certificate for dyndns.example. It doesn't matter how much entropy DigiCert put in the record name.

I definitely commend DigiCert for pledging to revoke the certificates within 24 hours and not having a delayed revocation or trying to language lawyer their way to a 5 day revocation as other CAs have tried. Nevertheless, this post severely minimizes the security impact of their mistake, and provides an excellent example of why CAs should always be required to strictly adhere to the rules and not be permitted to excuse noncompliance based on their own security analysis.

[michaelt]

> For example, if an attacker requests a certificate for dyndns.example

Shouldn't that get caught by the Public Suffix List?

I would hope DigiCert has checks in place to prevent someone domain-validating ownership of the entire of co.uk under any circumstances :)

(They should still revoke the mis-issued certificates though)

[agwa]

There's no prohibition against issuing certificates for names on the Public Suffix List.

BR 3.2.2.6 prohibits issuing a wildcard certificate for an entire public suffix unless the "Applicant proves its rightful control of the entire Domain Namespace" (without specifying how this should be done - arguably, publishing a DNS record would qualify) but also says that CAs should use the "ICANN DOMAINS" section of the PSL only, not the "PRIVATE DOMAINS" section, so domains for dynamic DNS providers and the like wouldn't be included. [https://github.com/cabforum/servercert/blob/main/docs/BR.md#...]

[nickf]

PSL has a couple of sections - ICANN and PRIVATE. PRIVATE can be a little more flexible/ignorable. If they implement a hard rule, then occasionally they'd have to make exceptions when the real Dyn comes along and wants (legitimately) a wildcard for their name.

[remus]

> Shouldn't that get caught by the Public Suffix List?

PSL is a best-effort sort of thing, so it's good but not definitive. It would be dangerous to rely on it when issuing certs imo.

[agwa]

> I definitely commend DigiCert for pledging to revoke the certificates within 24 hours and not having a delayed revocation or trying to language lawyer their way to a 5 day revocation as other CAs have tried.

It seems I spoke too soon: https://bugzilla.mozilla.org/show_bug.cgi?id=1910322#c8

[CaliforniaKarl]

Having a restraining order served on them is going to slow things down a bit.

[agwa]

That only affects 72 certificates. They've delayed revocation for all 83,000+.