SECOND MEASUREMENT SM-011

Firefox’s revocation list is months behind the biggest certificate logs. One in eleven top sites, mozilla.org included, gets no revocation check at all

Markovian ProtocolMeasured 2026-10-02Status: sent to Mozilla 2026-10-02, response pendingDOI: 10.5281/zenodo.23123261

Firefox decides whether a certificate is revoked from a list Mozilla builds by reading every public certificate log and every certificate authority’s revocation list. The list can only answer for certificates its builder has read, and it says, inside the file, how far into each log it has read. On 2 October that position was 12 June for Google’s Xenon2026h2 log, 28 June for DigiCert’s Wyvern2026h2 and 10 August for Sphinx2026h2: 1.66 billion, 956 million and 535 million entries behind. A certificate logged only to those logs is one the list has never seen, and for those Firefox skips the online check too. We fetched the live certificates of the 1,000 most-visited domains and asked the filters: 68 of 726 come back not covered, among them mozilla.org, stripe.com, medium.com, digicert.com and most of Google’s own properties. Their certificates are up to 50 days old. The logs themselves serve new entries in minutes; we timed them.

Disclosure: Markovian Protocol holds no financial position in any organisation named here, was paid by no one for this work, and showed it to no one before publication except the organisation measured. How we work.

What they said, what we found

How far behind, log by log

The coverage list in the newest filter, compared with the one in the 2 September snapshot. “Behind” is measured from the filter’s own effective time, 2 October 13:01 UTC.

All 22 tiled logs and the other usable classic logs (Argon2027h1, Sectigo, DigiCert 2027h2, Cloudflare) are within a day. TrustAsia log2026a and log2026b are listed usable by Google and Apple and accepted our test entry on 2 October. Full dumps for all 62 filters are in the exhibits.

What a reader at 12 June has not seen, by asking the log itself: a binary search over each log’s entries for the first timestamp past Mozilla’s cutoff.

Tree sizes from each log’s get-sth at about 00:15 UTC on 3 October. The 2026h2 shards hold the certificates that expire in the second half of 2026, which is most 90-day certificates in use today.

What that does to the sites people visit

A certificate is covered if any one of its embedded log timestamps falls inside the filter’s interval for that log. Most certificates carry two or three. A certificate logged to Argon2026h2 is fine; one logged to Xenon2026h2 and a DigiCert 2026h2 log is invisible. Google Trust Services, which issues for Google’s own domains and for anyone using Google Cloud, tends to use the second combination.

Not covered by rank: 20 in the top 250, 13 in 251–500, 17 in 501–750, 18 in 751–1,000. The 274 unreachable names are mostly CDN and mail domains with no web server at the apex. The Android channel gives the same 68. Extending the run to the top 5,000: 346 of 3,792 reachable sites not covered, 9.1%, 299 of them on Google Trust Services certificates.

The twenty highest-ranked:

63 of the 68 carry timestamps only from the lagging logs; the other five were issued within a day of the reader’s position and are the ordinary merge-delay case. Every one of the 68 carries timestamps only from logs with a 24-hour merge delay. The youngest is 9 hours old, the oldest 50 days; 61 of the 68 are more than two days old. The “new certificate” explanation does not reach them.

Whose certificates these are

Sort the uncovered certificates by who issued them and the picture changes from “sites” to one certificate authority. Google Trust Services issued 151 of the 726 top-1,000 certificates we could fetch and 57 of the 68 Firefox cannot check: more than a third of everything it issues to the busiest sites. Microsoft’s own CA is in the same state for its 18. DigiCert, with 139 certificates in the same set, has two. Let’s Encrypt, the largest issuer in the top 5,000, has seven of 773. The difference is where each CA sends its certificates to be logged. Of Google Trust Services’ 151 certificates in the top 1,000, 150 carry timestamps only from the older RFC 6962 logs (Google’s own Xenon and Argon first, then DigiCert’s, Cloudflare’s and TrustAsia’s), and every one of the 68 uncovered certificates has a log set drawn entirely from the lagging ones. Let’s Encrypt sends 124 of its 126 to at least one tiled log, which the reader keeps up with, and has none uncovered in the top 1,000. Sectigo sends 41 of 49 to a tiled log. The fix is a configuration choice at the CA, not a change to Firefox.

Whether the reader is catching up is now measured daily on the rechecks page. On the first two runs, a day apart, it fell a further half-day behind on Xenon2026h2, the largest log, and gained about a day on DigiCert’s two. At those rates it reaches today on the DigiCert logs in two to four months and on Google’s never; two runs is too few to call a trend, and the page will say when it is.

From the same census (topsites_results.json): issuer organisation from each certificate, coverage verdict from the newest filter. Issuers with no uncovered certificate in the top 1,000 are shown for the top 5,000 only.

How this ends

One of two acts closes it, and the daily recheck will show which: Mozilla’s reader reaches the current day on Xenon2026h2 and the other lagging logs, or Google Trust Services adds a tiled log to the set it submits every certificate to. Either one takes the uncovered count on the busiest sites to zero. Until then the number is printed each morning.

The evidence

Every quote below was copied from the source and checked against a saved copy, fetched 2026-10-02 and 03. The 62 coverage dumps, the live tree heads, the 726 certificates and the scripts are published next to this page (SHA256SUMS).

$ inspect 20261002-1-default.filter.delta        (clubcard-crlite, Mozilla)
                  CT Log ID                             Min Time        Max Time
  2AlVO5RPev/IFhlvlE+Fq7D4/F6HVSYPFdEucrtFSxQ=,  1718275427911,  1781304587929   Xenon2026h2: up to 2026-06-12 22:49
  ...
  RMK9DOkUDmSlyUoBkwpaobs1lw4A7hEWiWgqHETXtWY=,  0,  1790842110933   Xenon2027h1: up to 2026-10-01 08:08

GET https://ct.googleapis.com/logs/eu1/xenon2026h2/ct/v1/get-sth
  tree_size 2935526349, timestamp 2026-10-03 00:17:36 UTC
Our own entry, submitted 2026-10-02 21:46:56 UTC, served with an inclusion proof within 94 seconds.
Binary search for the first entry after 2026-06-12 22:49: index 1,273,229,307  ->  1,662,321,853 entries unread

certificate: CN=mozilla.org, issuer Google Trust Services WR3, notBefore 2026-09-14 09:15 UTC
embedded SCTs: Google Xenon2026h2 (2026-09-14 10:15:08), TrustAsia log2026a (2026-09-14 10:15:08)

$ rust-query-crlite -d db_fresh --update prod -vvv https mozilla.org
TRACE - 20260902-0-default.filter: NotCovered
TRACE - 20260902-1-default.filter.delta: NotCovered
  ... all 62 filters ...
INFO - mozilla.org NotCovered

Our questions to Mozilla

Sent to Mozilla’s CRLite maintainer on 2 October 2026 as mozilla/crlite issue 392, alongside SM-009’s issue 391. Answers will be printed here as written.

1. Is the lag on Xenon2026h2, Wyvern2026h2 and Sphinx2026h2 known, and is it capacity on the largest RFC 6962 shards or something else?
2. TrustAsia log2026a and log2026b are usable, accepting, and served our entry in under three minutes. Coverage stopped on 25 November 2025. Dropped on purpose?
3. Is the paper’s 5% uncovered figure still what telemetry shows, and does Mozilla track which logs the uncovered certificates come from?
4. Would the client be safer falling back to OCSP for an uncovered certificate older than one merge delay, now that the filter’s own metadata shows the gap isn’t the merge delay?

Their reply, scored

Disclosure timeline

Waiting on Mozilla since 2 Oct.

What we can’t be sure of

• This is one day’s filter and one day’s certificates. The per-filter series shows the lag has been there for at least a month and is growing on Xenon2026h2; it could be fixed tomorrow, and the daily recheck on the rechecks page will show it.
• “Not covered” means Firefox cannot use CRLite. A server that staples an OCSP response, or sends extra timestamps in the handshake, could still get a verdict. We tested the certificate as served to a plain TLS client.
• The top 1,000 domains are not the top 1,000 by Firefox traffic, and 274 of them had no web server to answer us. The share among what people actually load could be higher or lower.
• We measured the reader’s position from the filter’s own metadata and the logs’ own entries, not from inside Mozilla’s pipeline. The cause is Mozilla’s to explain.
• None of the 68 is known to be revoked. The finding is that Firefox would not know if one were.

Run it yourself

Rust for Mozilla’s two tools, Python 3 with cryptography. The whole thing runs in under half an hour.

git clone https://github.com/mozilla/crlite && cargo build --release --manifest-path crlite/rust-query-crlite/Cargo.toml
git clone https://github.com/mozilla/clubcard-crlite && cargo build --release --examples --manifest-path clubcard-crlite/Cargo.toml
rust-query-crlite -d db --update prod https mozilla.org          # downloads the 62 filters
for f in db/*.filter db/*.delta; do inspect "$f" > "coverage/$f.txt"; done
python3 unread_entries.py                                         # binary search each lagging log
python3 topsites_crlite.py 1000                                   # Tranco top 1,000, live certs, verdicts

Reproduced from the public repository on 3 October 2026 on a clean machine: exact (mozilla.org NotCovered; Xenon2026h2 read to 12 June, 1.66 billion entries unread). Full table on the track record.

What you can do with this

• If your certificate comes from Google Trust Services, more than a third of its peers have no revocation check in Firefox today; ask for timestamps from a tiled log.
• If you run a site in the top 1,000, check whether Firefox's filter covers your certificate with rust-query-crlite; the command is above.

References

1. J.C. Jones. The End-to-End Design of CRLite. Mozilla Security Blog, 9 January 2020. blog.mozilla.org.
2. John M. Schanck and others. Clubcards for the WebPKI: smaller certificate revocation tests in theory and practice. IEEE S&P 2025, section 5. research.mozilla.org.
3. Firefox source, security/certverifier/NSSCertDBTrustDomain.cpp, CheckRevocation; saved copy in SM-009’s exhibits.
4. mozilla/clubcard-crlite, src/query.rs, CRLiteClubcard::contains: the coverage rule. mozilla/crlite issue 366.
5. Tranco list, tranco-list.eu, downloaded 2 October 2026. Google and Apple CT log lists for log ids and merge delays.
6. J. Schanck et al. Comprehensive Revocation Checking at Scale: the Deployment of CRLite in Mozilla Firefox. ACM SIGCOMM 2026. doi.org/10.1145/3789240.3829108. Also N. Fooda, J. Larisch, J. Schanck, B. Maggs, T. Chung, D. Levin. A First Look at Certificate Revocation Latency. ACM IMC 2026. doi.org/10.1145/3777912.3839820.

Cite as

@misc{markovian-sm011,
  author = {{Markovian Protocol}},
  title  = {How far behind the logs Firefox's CRLite filter reads, October 2026},
  number = {SM-011},
  doi    = {10.5281/zenodo.23123261},
  year   = {2026},
  month  = oct,
  url    = {https://markovianprotocol.com/measurements/sm-011.html}
}