Nearly everything else just uses the WebPKI CAs without actually enforcing WebPKI rules beyond that. Some things hard-wire CA pins which is very risky without an out-of-band update mechanism. Few things do leaf pinning and those that do often fail to support rotation properly.
Conversation
Reality is that if you control DNS or at least can appear to control DNS, you can trivially obtain a valid Let's Encrypt or other CA certificate. It's not really misissuance if you don't have DNSSEC + CAA. Hardly anyone checks CT meaningfully beyond making sure it's the right CA.
1
1
I'm looking forward to Let's Encrypt deploying accounturi support to production. They have it in staging (used for dry runs by certbot, etc.) but I can't get information on when it's going to be deployed to production. We use that for grapheneos.org, etc. alongside TLSA.
1
1
1
Look at the CAA records for grapheneos.org and then one of the subdomains like matrix.grapheneos.org. They each have their staging and production accounturi pinned for Let's Encrypt. It'll be nice when they start enforcing in prod. TLSA in browsers would ofc be nicer.
1
1
accounturi at least makes certificate issuance secure for the CA you choose to trust. It doesn't stop other CAs from ignoring DNSSEC/CAA, being compromised, etc. but at least for us our users can assume it's an invalid certificate if it's not Let's Encrypt which is easy to check.
2
If CT requires the CA to publish the CAA record they used to issue it and the signature chain leading to the CAA record, clients could automatically reject fraudulently generated certs.
1
The way it works is they know the domain they control for it and they know the format of their extended options such as accounturi and validationmethods. I don't really think a client could easily enforce CAA records even with that approach. It's not really designed for it.
2
I don't think the # of CAs is really even bounded. Let's Encrypt was a working, trusted CA before they had their ISRG root in CA programs. CA programs also didn't explicitly approve the cross-signing of their root. It may have had to be disclosed, but not explicitly approved.
1
Let's Encrypt decided that their CAA domain would be letsencrypt.org and CA programs / browsers aren't aware of it or any the other values.
Any CA can just unilaterally decide that they are authorizing another CA via cross-sign. They just may be required to disclose it.
1
And I'm sure any sub-CA is meant to follow the same rules and the CA who authorizes them is supposedly responsible for it.
If they actually serve a ton of users, CA programs are super reluctant to remove them even if they make really sketchy / bad choices about sub-CAs.
1
So, for example, if LE had turned out to be an incompetent disaster (which it clearly isn't, but pretend it had) it's super unlikely that the root used to cross-sign them would have been untrusted for causing that problem even if it was extremely bad / negligent.