Embedded SCT distribution dashboard

[Filippo Valsorda]

Hello humans and critters,

I could not find an easily accessible data source for the distribution among logs of embedded SCTs, so I built a dashboard based on Censys research access and exe.dev, based on an idea by Matthew McPherrin.

https://sctdata.geomys.org 

Every day, the system fetches counts for cert.labels = "trusted" and cert.labels = "leaf" with a cert.parsed.validity_period.not_before range in the previous day, and buckets by cert.parsed.extensions.signed_certificate_timestamps.log_id. It also runs the same queries filtered by cert.parsed.issuer.organization to each of the most popular CAs.

This data is a better indicator of log usage among CAs than log growth rates, because the latter are affected by cross-posting and full certificate posting policies.

There are a few nice insights in the data. First, if you untick Group series you can clearly see the shift from 2026h1 to 2026h2 a couple days ago.

You can also clearly see when Let's Encrypt moved to prefer Static CT logs on 2026-03-27, going from 

to

where neon green is Let's Encrypt, purple is Geomys, and gold is IPng.

Unfortunately, Let's Encrypt appears to be the only CA uniformly spreading load among Usable logs. Other CAs mostly use Google, DigiCert, and Sectigo logs. 

In particular, among the larger CAs

• GTS uses a mix of RFC 6962 logs
• Sectigo uses Google Argon and Sectigo Tiger
• GoDaddy uses Google Argon, the two DigiCert logs, and Cloudflare Nimbus
• DigiCert uses Google and DigiCert logs.
  

It would be nice to hear from these CAs if they encountered any issues with Static CT logs, and from the community on whether better load balancing is something we should try to encourage more.

The whole system was built by Claude Opus 4.6 in the Shelley harness, and I have not seen the code, so I am not releasing it as vetting it properly would take longer than it took to produce the dashboard. Improvement suggestions are welcome.

Alla prossima,

Filippo

[Seo Suchan]

I wonder if they are submit to other logs but prefer to using STCs from their log (and others only as backup): it's too low to be visible in % view but they are have hundreds of certs per day they used different log from their prefered. 

looks like most CAs use at least one google log due to old rule

2026년 4월 4일 토요일 PM 10시 2분 10초 UTC+9에 Filippo Valsorda님이 작성:

[John Schanck]

Hi all,

Thanks for putting this together, Filippo!

I would be very happy to see better load balancing and, in particular, more
embedded SCTs from Static CT logs. There are a two ways that this would improve
CRLite:

1) A revocation status of a certificate is only visible through CRLite after
   the merge window around at least one of its embedded SCTs has closed. Since
   Static CT logs have short MMDs (usually 1 minute), certificates with
   embedded SCTs from Static CT logs get included in CRLite quickly.

2) Mozilla's CRLite aggregator has a much easier time tailing Static CT logs
   than it does tailing RFC 6962 logs. I have my own vibe coded dashboard here [1]
   which shows that we are struggling with DigiCert Wyvern / Sphinx, Google
   Xenon, and TrustAsia 2026a/b. Certificates that only embed SCTs from these
   logs get included in CRLite slowly, if at all.

Cheers,
John

[1] https://finiterealities.net/crl_audit.html

--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/718571cb-a841-4102-bcfa-3fe3feab63ae%40app.fastmail.com.

[Freddy Zhang]

Thank you for building this dashboard! It's nice to see the current state of the SCT distribution in the ecosystem.

An update from the GTS side: We currently use this open source GitHub library for submitting our certs to the CT logs. The implementation needs updates to better reflect the current browsers’ root program requirements (e.g., no longer requiring one Google CT log and supporting static CT logs). To address this, we have started a GitHub issue to refactor the submission library, in collaboration with LE. The goal is to create a more robust and unified CT submission logic for all CAs to use and continuously iterate upon.

In the meantime, we plan to work on a solution internally to be able to support static CT logs and anticipate to start submitting to them in the second half of 2026.

Thanks,

Freddy / GTS Team

[Rob Stradling]

> Sectigo uses Google Argon and Sectigo Tiger

So far we've always used a manually-configured, fixed list of logs, and we typically only adjust that list when one of those logs is down or struggling.  It's long been a TODO list item for us to implement a more intelligent, robust, fault-tolerant, etc approach...and on that note...

I'm currently building a to-be-open-sourced submission proxy, which will track Usable logs and (for each submission) obtain SCTs from a suitable quorum.  We'll be using this at Sectigo once it's ready, and I'm hoping it'll also prove to be useful to other CAs.  By default it'll require at least one RFC6962 SCT (because this is still an Apple CT Policy requirement) and prefer at least one Static SCT.  More details to follow, hopefully before the end of this month.