For the people wondering why this does not show up as revoked in their browser: I believe the way the current revocation systems work is that browsers compile centralized lists of revoked certificates, but they do not contain all revoked certs, but only ones that indicate some form of security issue.

Certificates can be revoked with various revocation reasons, however, it looks this one has no specific revocation reason listed in the CRL. For a certificate that was revoked with a reason of "Key Compromise", things would be different, and most browsers would probably reject it.

Firefox / CRLite includes all revocations. The issue with this particular certificate is that the CRLite backend is behind on ingesting both of the CT logs that it appears in (Digicert wyvern2025h2 [1] and Let's Encrypt oak2025h2). So from CRLite's perspective the certificate doesn't exist yet.

In the very near future, CAs are going to start embedding signed CT timestamps from "static CT" logs [2]. Once that happens, the CRLite backend will be aware of certificates within minutes of issuance.

[1] The wyvern2025h2 shard had an outage last week, which is also part of the problem here https://groups.google.com/a/chromium.org/g/ct-policy/c/XpmIf....

[2] https://github.com/C2SP/C2SP/blob/main/static-ct-api.md

What would be the point of accepting a certificate that was revoked for non-security reasons?

Might as well not even revoke it…

If a CA issues a certificate to the wrong entity, they won’t have knowledge of a key compromise as there is no such thing in this case — they only know that they issued something wrong…

I believe I remember reading that chrome has a seperate system for revoking CA certificates, where they have to do a manual rollout, but propagation time is pretty fast.

[citation needed]