SECOND MEASUREMENT SM-015

Certificate Transparency’s new tiled logs publish in seconds. The old ones take up to an hour, and the browsers’ own log lists are the slowest part

Markovian ProtocolMeasured 2026-10-02 and 2026-10-03Status: published 2026-10-03; questions sent to Apple’s and Chrome’s CT programs 2026-10-03, responses pendingDOI: 10.5281/zenodo.23123269

Every certificate a browser trusts has to be written into public logs first, so that anyone can see which certificates exist for a name. The logs come in two generations now. The original design, RFC 6962 from 2013, lets a log promise to include a certificate “soon”, with a maximum merge delay that most logs set at 24 hours. The new design, static-ct-api, serves the log as plain files and hands out a certificate’s position at the moment it is accepted, so there is nothing left to wait for. We tested both the same way: our own certificate, submitted to every log Chrome trusts, each log polled until it served the entry. All 43 tiled logs served it inside six seconds, most in a fifth of one. The 21 older logs took between ten seconds and an hour. Then we read what the two big browsers’ log lists say, because a list is what a certificate authority and a browser actually consult. Apple’s list hasn’t changed since 31 March and still marks twelve logs “usable” whose windows closed three months ago. Chrome’s list admits four shards whose windows run two weeks past Chrome’s own one-year rule, and declares a 24-hour merge delay for 21 logs under a policy that caps it at four. The logs have become fast. The paperwork around them has not.

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 organisations measured. We operate a witness that cosigns several of these logs. How we work.

What they said, what we found

How long each log took

Cloudflare’s two Nimbus logs are the only ones in Chrome’s list that took longer than three minutes (its three tiled Raio logs, on Apple’s list, answered in about a second), and the hour they take is also the gap Firefox’s revocation reader waits on (SM-009). Nothing here breaks a rule; 24 hours is the rule. The point is the distance between what the rule allows and what everyone but Cloudflare now does.

The lists

A certificate authority doesn’t read a log’s API to decide where to submit; it reads the browsers’ lists. Apple publishes one JSON file and Chrome another, and both carry a state per log and a window of certificate expiry dates the log accepts. When the window closes the log stops taking submissions. Chrome’s list no longer carries them; Apple’s list has not been touched since 31 March.

Apple’s program page, updated 3 September, defines usable as a log whose SCTs “can be relied on to meet Apple’s client CT policy” and says nothing about when a closed shard leaves that state. The list it governs was built on 31 March. Chrome’s list, fetched the day after Apple’s, was version 93.2, stamped 2 October at 13:40 UTC.

The four TrustAsia shards are the other list finding. Chrome’s policy says a window “must be no longer than one calendar year”; log2026a and log2026b run from 24 December 2025 to 8 January 2027, 380 days, and the two 2027 shards the same. The convenience is obvious, a week either side of the year boundary. So is the word “must”. And the policy’s four-hour cap on an RFC 6962 log’s MMD sits beside a list that declares 24 hours for all 21 of them; whichever is current, the other is wrong.

How this ends

Three small acts, each visible on the daily recheck: Apple publishes a new log list and the twelve closed shards leave “usable”; Chrome’s list and its policy say the same merge delay for RFC 6962 logs; the four 380-day shards reach their end and no successor exceeds a year. The logs themselves need nothing; the lists do.

The evidence

Every quote below was copied from the source and checked against a saved copy, fetched 2 or 3 October 2026. Both lists, the policy pages, the per-log measurements and the scripts are published next to this page (SHA256SUMS).

log_list.json v93.2, 2026-10-02T13:40:14Z: 64 usable or qualified logs
  tiled_logs: 43, "mmd": 60
  logs (RFC 6962): 21, "mmd": 86400
  TrustAsia 'log2026a'  temporal_interval 2025-12-24 → 2027-01-08   380 days
  TrustAsia 'log2026b'  2025-12-24 → 2027-01-08   380      HETU2027  2026-12-25 → 2028-01-08   379      Luoshu2027  2026-12-24 → 2028-01-08   380

valid.apple.com/ct/log_list/current_log_list.json   version 511
Last-Modified: Tue, 31 Mar 2026 16:17:29 GMT   Content-Length: 148409
"usable" with temporal_interval.end_exclusive in the past: 12
  log.willow.ct.letsencrypt.org/2026h1    end 2026-06-17   Google 'Argon 2026H1' log   end 2026-07-01   …

merge delay (ct_mmd.py, 2026-10-02): 64 logs, our chain, polled until served
  tiled      43   max 5.7 s   median 0.2 s
  RFC 6962   21   DigiCert 10–11 s · Google 1.2–1.6 min · Sectigo 0.7–1.7 min · TrustAsia 0.7–2.5 min · Cloudflare 46.0 / 60.6 min
accepted roots (get_roots.py, 2026-10-03): 64 logs vs 101 Chrome-included roots
  all 101: 30 logs   missing 1: 29   missing 6: Sphinx ×3   missing 25: Nimbus2026, Nimbus2027   Merge Delay Monitor Root: 64/64

Our questions

Sent on 3 October 2026 to Apple’s Certificate Transparency program and to Chrome’s. Answers will be printed here as written.

1. Apple: twelve logs on the current list are marked usable although their windows closed in June and July. When does a closed shard leave the usable state, and is the list’s 31 March build date intended?
2. Chrome: the policy caps an RFC 6962 log’s MMD at four hours; the list declares 24 hours for all 21. Which governs, and will the list change?
3. Chrome: four TrustAsia shards run 379 and 380 days against “no longer than one calendar year”. Was an exception granted, and is the rule read as inclusive of the boundary weeks?
4. Both: Cloudflare’s Nimbus logs accept 76 of the 101 Chrome roots. Is “expected to accept” monitored, and at what shortfall does it matter?

Their reply, scored

Disclosure timeline

Waiting since 3 Oct.

What we can’t be sure of

• One certificate, one day, one vantage point. A log’s merge delay varies with load; our numbers are one sample per log and the polling interval adds up to a few seconds to each. The order of magnitude between the two designs is not within that noise.
• Chrome’s policy page is read as of 3 October. If the four-hour MMD cap was added after the 21 logs were admitted, the list and the policy disagree by history rather than by error; the question above asks which.
• “Expected to accept” is not “must”. We report the shortfall and have told the two operators; we don’t call it a breach.
• Apple’s usable state may carry an internal grace period its page doesn’t state. A CA reading the list today would still try to submit to a log that cannot accept.
• We operate a witness that cosigns some of the tiled logs measured here. The merge-delay measurement does not use it.

Run it yourself

Python 3 standard library plus the cryptography package for the chain. A certificate you control, submitted to 64 logs; a few minutes for the fast ones, an hour for Cloudflare.

python3 ct_mmd.py --chain chain.pem           # submit to every usable/qualified log, poll until served
python3 get_roots.py                           # accepted roots per log vs the CCADB's Chrome-included set
python3 analyze_lists.py                       # shard windows and Apple's closed-but-usable shards

Reproduced from the public repository on 3 October 2026 on a clean machine: the root and list results are exact (30 logs accept all 101 roots, four 380-day shards, 12 closed shards usable on Apple's list). The merge-delay measurement needs a publicly trusted certificate chain of your own. Full table on the track record.

What you can do with this

• If you run a CA, submit to a tiled log for the fast SCT and a classic one for breadth; Cloudflare's classic logs take an hour and refuse 25 roots.
• If you read Apple's log list to choose logs, twelve usable entries cannot accept a certificate today; check the window before submitting.

References

1. Google. Chrome Certificate Transparency Log Policy. googlechrome.github.io/CertificateTransparency/log_policy.html.
2. Apple. Apple’s Certificate Transparency log program, support article 103703. support.apple.com/en-us/103703.
3. C2SP. static-ct-api. c2sp.org/static-ct-api.
4. B. Laurie, A. Langley, E. Kasper. Certificate Transparency, RFC 6962, 2013. rfc-editor.org/rfc/rfc6962.
5. Google. Chrome CT log list v3. gstatic.com/ct/log_list/v3/log_list.json. Apple. Current log list. valid.apple.com.

Cite as

@misc{markovian-sm015,
  author = {{Markovian Protocol}},
  title  = {Merge delay, accepted roots and list hygiene across the 64 Chrome-trusted CT logs, October 2026},
  number = {SM-015},
  doi    = {10.5281/zenodo.23123269},
  year   = {2026},
  month  = oct,
  url    = {https://markovianprotocol.com/measurements/sm-015.html}
}