Trust Model for CT Logs?

[Vasily Suvorov]

Hi all,

I've been implementing a monitor for "tiled logs" , which is also checking the entries against the merkle tree. One aspect that is not clear to me is whether or not one is supposed to trust the fingerprints of the issuer certificates' chain that are returned by the log.

Shall I, for example, once the entries are parsed and their hashes checked, also retrieve the issuer certificates (using the fingerprints) and then check that they, in fact, build a correct verification chain? 

I feel the real answer is that all checks have to be performed, in order to ensure compliance and integrity. Or is it too impractical? 

I'd appreciate your thoughts!

Best regards,

Vasily

[Philippe Boneff]

Hi Vasily,

Logs are indeed required to serve a valid fingerprint chain and to make the corresponding intermediate certificates available to be compliant. It's always a plus to check for this if you can. In most cases, a failure to present a valid issuer chain shouldn't compromise the integrity of the log because these structures are not hashed.

However, the MerkleTreeLeaf of PreCert entries contains the issuer_key_hash. A wrong value there would compromise the integrity of the tree, so this one should definitely be checked. As a matter of fact, failures because of this have happened before. It also turns out that as of 3 days ago, Precertificate Signing CAs are not allowed to be used anymore, which should make these failures less likely to happen.

Cheers,
Philippe

--
You received this message because you are subscribed to the Google Groups "certificate-transparency" group.
To unsubscribe from this group and stop receiving emails from it, send an email to certificate-transp...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/certificate-transparency/05086b0a-8371-49dd-bb84-35e8ec8a1b0cn%40googlegroups.com.

[Vasiliy Suvorov]

Hi Philippe,

Thanks a lot for the advice, very helpful!

I've implemented the checking of both the issuer's key hash (for the precerts), as well as the issuers' chain. I've been tailing a few logs over the last few days and all checks out, so far :)

What I find interesting, is that Gouda2026h1 seems to be the most used Static CT log, judging at least by the update speed. Another random observation is that HTTP1 works better than HTTP2 for whatever reason, I get a smaller amount of timeouts, resets, etc. 

Regarding the logs' usage by the CAs. How do the CAs decide which logs to use to get the SCTs? Also, is there a momentum to use Static CT logs vs RFC6962 ones? 

I'm wondering if it's worth the effort to support the RFC logs. 

Best regards,

Vasily

To view this discussion visit https://groups.google.com/d/msgid/certificate-transparency/CAOzAejTHDyg2-bNhxwYm7_KKLqzKdSQ5feecHatweuKJCDukCQ%40mail.gmail.com.

[Jeroen Massar]

> On 24 Mar 2026, at 13:39, Vasiliy Suvorov <vsuv...@gmail.com> wrote:
> [..]

> What I find interesting, is that Gouda2026h1 seems to be the most used Static CT log, judging at least by the update speed.

This might partially be because of cross-posting unfortunately, but a bit unknown why some get more than others: more research needed...


https://radar.cloudflare.com/certificate-transparency has some details on the different logs to easily check up on them.


According to that, Halloumi (Tesseract) gets double the amount of certificates than Gouda (Sunlight), which both is indeed multiples of Geomys's Tuscolo (Sunlight).

https://radar.cloudflare.com/explorer?dataSet=ct&groupBy=log_operator can also be useful in exploring differences between logs. Setting that to "CT log API" you will see ~3.5M / 589M for RFC6962, and ~500K / 141Mfor static-ct-api for last 7 days.
For last year 35B versus 11B in total, thus about a third.

> Another random observation is that HTTP1 works better than HTTP2 for whatever reason, I get a smaller amount of timeouts, resets, etc.

For Gouda? If yes, then do not hesitate to discuss here or send some details to ct-...@ipng.ch <mailto:ct-...@ipng.ch> so we can investigate.

Noting that Halloumi and Gouda HTTP frontends are the same, they do end up on two separate VMs on two separate hosts, network behind that is shared.
Any deltas could thus be hardware/cpu/mem/disk or CT Log implementation.
The other could be your path to the HTTP frontends as they log are are spread over 2 and the mon hosts over 3 separate ASN.

Hence do ensure you compare based on IP (be that IPv4 + IPv6) what you are hitting as that might cause a delta too.

> Regarding the logs' usage by the CAs. How do the CAs decide which logs to use to get the SCTs? Also, is there a momentum to use Static CT logs vs RFC6962 ones?
>
> I'm wondering if it's worth the effort to support the RFC logs.

Matthew & Filippo's excellent post has some details on that:
https://letsencrypt.org/2024/03/14/introducing-sunlight


the title gives it away though "A CT implementation built for scalability, ease of operation, and reduced cost"

note that that states 'reduced cost', not 'low cost'... but eh ;)

Regards,
Jeroen

[Vasiliy Suvorov]

Hi Jeroen,

Yes, I've seen the "radar" and I do need to spend more time playing with the dataset, thanks for reminding me!

Re, update speed - I've just added Raio2026h1 to the monitoring roster and, unexpectedly, it's a busy log. I've already seen it spike to 130+ new entities per second. 

Which adds to the whole mystery of how some CAs select the logs to post to. It's formally 'rejected'! I guess the brand plays a big role.

On HTTP2, I do need to play more and add an actual telemetry to my application, right now I'm looking at the logs as my focus has been more on getting the retrieval and verification logic to work correctly. 

But I do use ipv6, I'm actually on AS13030, so a short 'Katzensprung' away, in a manner of speaking. 

BTW, on the "cross posters", I did notice that some CAs, or someone on their behalf, submit a fair amount of final certificates. E.g. Let's Encrypt and ZeroSSL, to name a few. Which is somewhat surprising to me, as SCT delivery over TLS is not very popular, I believe. 

And I do agree that static ct logs make a lot of sense. Getting the head around the tiled Merkle Tree structure with optimized intermediate layers and the need to deal with dynamically changing 'edge tiles' was a delightful challenge.

After mastering that, I feel that it provides the ultimate transparency and ability to really check everything almost in real time.  In fact, having this experience, looking at the RFC6962 APIs makes me uncomfortable :)

Cheers,

Vasily

--
You received this message because you are subscribed to the Google Groups "certificate-transparency" group.
To unsubscribe from this group and stop receiving emails from it, send an email to certificate-transp...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/certificate-transparency/4AADE6E2-B6F5-4E77-A3DC-F73D91F02DAF%40massar.ch.

[Luke Valenta]

Hi Vasiliy,

Cloudflare runs a load tester against the Raio log shards (cross-posting entries from another independent log shard), which explains the high numbers you are seeing. In general, log volume is not a great metric for how useful a log is to the ecosystem (or even which CAs use which logs to fetch SCTs, since cross-posting is so prevalent).

You can see some of the reasons CAs log final certificates discussed in this thread: https://groups.google.com/a/chromium.org/g/ct-policy/c/03pvIpmMpeI/m/yzN5vrSVAAAJ.

Best,

Luke

To view this discussion visit https://groups.google.com/d/msgid/certificate-transparency/CAG0HsoHL7UhZg94R_WXWDHye0WBBrnw0nMNbagUzhXV1MOcvEA%40mail.gmail.com.

--

Luke Valenta

Systems Engineer - Research