[low_key]

PSA: The unbounded checker doesn't seem to work if you have certificates issued for both ECC and RSA keys. For some of mine, it passes the check with status "OK" and shows the serial number of the certificate for the ECC key. The certificate that is going to be revoked is not shown.

[tialaramex]

If you have more than one certificate in use, regardless of what flavour, they only see one and assess that. Maybe the checker should emphasise that. For small users they probably only have one certificate in use, so this avoids some problems.

The issue would probably also affect people who have geographically separate certificates e.g. if you have two servers in different regions and decided rather than make things more complicated for key distribution you'll just have them each get their own certificates for the same name - that's totally fine with Let's Encrypt (it doesn't scale, but if you had 500 servers not 2 you'd probably redesign everything) but obviously this test only sees one of those servers and won't check the other certificate.

There's no way to know, given that two (or more) valid certificates exist for a name, and seeing one of them, whether the others are still actively used anywhere.

It would obviously be pretty easy to build a web form where you can type in an FQDN and get told if any certificates matching that name will be revoked, but then you get false positives where it says yes, this certificate for some.name.example will be revoked, you rush to replace your certificate for some.name.example but maybe actually the one that will be revoked is from 20 December 2019, and you already got a newer one which was unaffected in February.

[namibj]

I wish they'd issue short-term scoped CAs under the same criteria as they currently use for wildcards.

No significant load on their infrastructure, and you'd not have to break the "private keys don't move over _any_ network" rule.

[tialaramex]

https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/

Delegated Credentials is the proposed mechanism to do what you actually want to achieve here. The certificate issuance is mostly the same except there's an OID 1.3.6.1.4.1.44363.44 and the digitalSignature KU is present meaning this certificate is intended to be used with Delegated Credentials and thus can sign things.

Although tightly constrained subCAs (which is roughly what you're describing) might be a way to achieve your goal, it's seen as disproportionately complicated and risky, so hence this proposed much more narrowly defined new feature for TLS.