mozilla
revoked-isrgrootx1.letsencrypt.org not showing up as revoked
This is a bit worrying to me, the main ISRG Root X1 revocation test that updated its certs a few days ago (05/11) is not being detected as revoked by any of my Firefox installs. Notably Firefox configured with Phoenix and IronFox. Meanwhile, the test for X2 shows as revoked properly, which was created just a few days before that (01/11).
OCSP is off, only CRLite is on
The security_state folder inside my profile is also showing as if it was updated just today/yesterday. It has been only like 6 days though, am I expecting too much?
Thanks for this report! This is very similar to Bug #367.
The precertificate was submitted to oak2026h1 and xenon2026h1. Both of these logs have 24 hour merge delays. The final certificate was submitted to several other logs, some of which have 1 minute merge delays. For example, it was logged in willow2026h1 at 2025-11-05 18:37:34 UTC.
The CRLite aggregator publishes a sequence of clubcards that temporally partition the set of revoked certificates. The clubcard that includes the revoked status for a certificate is the first clubcard that is published after that certificate is both revoked and "covered". A certificate is "covered" if the CRLite aggregator has seen it in a CT log and the merge window around the corresponding log entry has closed.
In this case, the CRLite backend ingested the certificate from willow2026h1 late on the 5th. Because willow2026h1 has a one minute merge delay, the backend considered the certificate covered late on the 5th as well. The backend correctly produced a clubcard on the 6th which marks the certificate as revoked.
Unfortunately, clients decide which clubcards to query based on the SCTs that a certificate is presented with. And the embedded SCTs from oak2026h1 and xenon2026h1 do not assert coverage until the 7th. As such, the "revoked" status is masked by an "unknown" status, as in Bug #367.
The certificate would correctly show as revoked in Firefox if it was presented with its timestamp from willow2026h1. I added a "query_with_timestamp" example to clubcard-crlite to test this:
$ cargo run --example query_with_timestamp 20251106-0-default.filter.delta int.pem ee.pem 4yON8o2iiOCq4Kzw+pDJhfC2v/XSpSewAfwcRFjEtug= 1762367854000
Revoked
This problem will more or less resolve itself once CAs start logging precertificates to static CT logs. Let's Encrypt plans to do that very soon. We could rework the patch for #367 to hold x509 certs in cache longer than we hold precertificates in cache. But this would require client-side changes as well, as it would change the coverage calculation for non-embedded SCTs.
The new certificate for https://revoked-isrgrootx1.letsencrypt.org/ has an embedded SCT from a log with a short merge delay. As expected, it is being shown as revoked in CRLite / Firefox.
$ rust-query-crlite -vv --update prod https revoked-isrgrootx1.letsencrypt.org
[...]
DEBUG - Loaded certificate from revoked-isrgrootx1.letsencrypt.org
DEBUG - Issuer DN: C=US, O=Let's Encrypt, CN=R12
DEBUG - Subject DN: CN=revoked-isrgrootx1.letsencrypt.org
DEBUG - Serial number: 0549ba691493288f4986403391a5f926c143
DEBUG - Issuer SPKI hash: kZwN96eHtZftBWrOZUsd6cA4es80n3NzSk_XtYz2EqQ=
TRACE - 20251203-1-default.filter: NotCovered
TRACE - 20251204-0-default.filter.delta: Revoked
INFO - revoked-isrgrootx1.letsencrypt.org Revoked