Hello,
I'm Kosei Akama, a Japanese student.
I am writing to inquire about the list of CT Logs used by Let's Encrypt.
Specifically, I would like to know which CT Logs Let's Encrypt utilizes.
I plan to use this information for my research.
Thank you.
1 Like
I don't know if they publicly announce what their current list of logs is; they probably want the flexibility to change it quickly if needed. I've changed this topic to the "Issuance Policy" category and it may be that someone from Let's Encrypt will respond.
In terms of just monitoring logs, if you haven't seen it yet you may want to check out Cloudflare's "Merkle Town" site giving Certificate Transparency statistics.
Near the bottom you can see a breakdown of the non-expired precertificates by log that are issued by Internet Security Research Group (which is the organization that runs Let's Encrypt).
7 Likes
Thank you so much for your helpful reply!
This site is very interesting.
I would also like to know the breakdown of ‘other’,
so I will wait for an answer for a while.
Thank you again for your assistance.
5 Likes
Let’s Encrypt submits to logs on the Chrome and Apple log lists.
You can find those lists at
and
5 Likes
The data shown on Cloudflare's Merkle Town is rendered client-side from a raw JSON object included in the main page, so it's actually possible to reconstruct "other" by building the data from raw ourselves*:
As of 20024-08-27 15:03 UTC:
Certificates issued by ISRG/Let's Encrypt:
{
"Name": "Internet Security Research Group",
"Data": {
"Cloudflare Nimbus2024": 70463641,
"DigiCert Sphinx2024h2": 101,
"DigiCert Wyvern2024h2": 98,
"DigiCert Yeti2024": 642901053,
"Google Argon2024": 365120769,
"Google Xenon2024": 365145412,
"Let's Encrypt Oak2024H2": 326457604,
"Sectigo Mammoth2024h2": 158144652,
"Sectigo Sabre": 82062,
"Sectigo Sabre2024h2": 161453765,
"TrustAsia Log2024-2": 2983
}
}
*You can fetch this for yourself by looking at view-source:https://ct.cloudflare.com/ in your browser, extract the JSON for the JS var named "preload", then look for the JSON key
/index.Utilization
Also note that Cloudflare's Merkle Town stops monitoring/displaying logs that are expired, so this data only includes certificates issued in the last few months (in particular Cloudflare has already removed the 2024h1 logs, as those are no longer accepting new entries)
7 Likes
Isn't it a little bit weird to already remove logs that include non-expired certificates?
4 Likes
All 2024h1 logs only include expired certificates, because the "Certificate Lifetime criterion" filters by expiration date: Logs only accept certificates whose expiry date falls within their own validity period.
8 Likes
For the section at the bottom, yes, it's only non-expired precertificates. The section at the top with general statistics is I think for all CT logs that their monitoring has ever seen. (Which is why one pie chart shows 85% as expired.) One needs to be a little careful when looking through it all exactly what subsets of what data are being shown where.
They're working on overhauling the page at some point, so hopefully they'll make things even clearer in the future.
6 Likes
Ah yeah, I missed that it says non-expired only, then the h1 removal indeed doesn't matter for that stat. I initially thought it also included expired (but still recent) certs.
5 Likes
Uch, true true, I always get that incorrect.. It's not the notBefore date, but the notAfter date..
4 Likes
Thank you for everything. Your comments have been incredibly helpful.
4 Likes
I also have a question: Do the statistics on Cloudflare’s site include logs submitted by non-CAs? From what I understand, anyone can submit certificates to CT logs if they are issued by a CA. Let’s Encrypt Documentation on CT Logs
Cloudflare stats doesn’t know who submits a cert to a log. It’s not really possible to know who made a submission to a log except by guessing based on patterns of behaviour.
6 Likes
I mean, presumably SCTs in the certificates themselves were from the CA submitting the precertificates itself. So because Let's Encrypt submits their final certificates to CT logs as well (which not all CAs do), one could crawl through all those and get the list of what logs were used, or at least what logs can answer quickly enough to get their SCTs embedded.
A lot of work for not really a lot of benefit, though, they basically just submit everything everywhere. 
5 Likes
I think it's relevant to distinguish between final certificates and pre-certificates here:
For pre-certs specifically, they will always be submitted to logs first by the issuing CA: The CA has to sign the pre-cert, submit that to CT logs, get the SCTs back, then produce the final certificate with SCTs included. The final certificate doesn't have to be sent to CT, but some CAs may do so anyway. The pre-cert thus cannot initially be submitted by anyone else but the issuing CA. This is different for final certificates: The CA doesn't have to log those, so it's perfectly possible that the initial submission (if any) is done by a third party, and not the CA itself.
After a certificate has already been issued, someone could technically crawl the CT log for that pre-cert and go ahead and re-submit that pre-cert to a different log. I think it's more common for third parties to find leaf certificates (which are actually used in TLS) and submit those to CT logs. I'm inclined to believe that pre-certs are primarily submitted by the CAs themselves, while leaf certificates will likely be submitted by various third parties (in addition to the CA, if it logs final certificates).
The "utilization" statistic on Cloudflare's Merkle Town claims it only counts pre-certs. Thus I believe the main submitter will be the CA itself, though technically it is possible for third parties to re-submit pre-certs as well. I don't have any statistics how common the latter is.
7 Likes
Thank you for all the helpful advice!
5 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.