We have finally built our own lookup table for all the Chromium recognized CT logs (5.6 billion lookup entries and counting). Our goal is to provide real-time KeyChest notifications of new certificates - especially when issued by an unexpected CAs.
Anyway - we can be only as good as the source and here’s some initial data, with a bit more about the growth of CT logs in my blog:
COMODO updates its logs mammoth and sabre every 10 minutes;
DigiCert has 60 minute update intervals for the series of yeti logs (yeti2018, yeti2019, yeti2020, yeti2021 and yeti2022), just like Google for most of their CT logs;
Symantec logs (ct, sirius and vega) are slowest - updates every 6 hours.
Google also has super fast Argon CT logs, which update in real-time (certainly within our 30 second checks).
EDIT: I was looking at the lag of CT logs themselves. Some comments mention crt.sh or other services. These are aggregators of CT logs with search capabilities. If you use these, you have to combine the latency of CT logs and the latency of this aggregation service.
https://crt.sh/can be very fast when it’s not backlogged or down. The backlog has been going down steadily of late, but currently the website is frozen on September 9 due to a database replication issue.
But if a certificate is logged to a fast, low traffic log with no backlog, it can be up in a few minutes. (I used to think crt.sh checked for new certificates every 10 minutes, but I think that might have changed.)
I believe there’s a bit of misunderstanding around this topic here. crt.sh is not a CT log, it’s a service, which collects data from CT logs and allows you to run queries.
What I was looking at was how long it takes the actual CT logs to update. Services like the one we are building for KeyChest.net, or crt.sh may add an additional latency - we are aiming for less than 10 seconds though.
