You Should Run a Certificate Transparency Log
30 comments
·July 7, 2025agwa
eddythompson80
I wonder if this is the solution something like SponsorBlock is looking for[1][2]. They have a similar-ish problem. How to replicate crowdsourced data that trickles in slowly, but ideally you want replicated quickly.
WAL replication, rsync, bittorrent, etc all things that don't quite work as needed.
[1] https://github.com/mchangrh/sb-mirror/blob/main/docs/breakdo...
gslin
The original article seems deleted, so https://archive.ph/TTXnK this.
FiloSottile
My bad! This is what I get for doing a deploy to fix the layout while the post is on HN. Back up now.
gslin
> You Should Run a Certificate Transparency Log
And:
> Bandwidth: 2 – 3 Gbps outbound.
I am not sure if this is correct, is 2-3Gbps really required for CT?
torbid
These sound like good improvements but I still don't really get why the ct log server is responsible for storage at all (as a 3rd party entity)..
Couldn't it just be responsible for its own key and signing incremental advances to a log that all publishers are responsible for storing up to their latest submission to it?
If it needed to restart and some last publisher couldn't give it its latest entries, well they would deserve that rollback to the last publish from a good publisher..
singron
The publishers can't entirely do the storage themselves since the whole point of CT is that they can't retract anything. If they did their own storage, they could rollback any change. Even if the log forms a verification chain, they could do a rollback shortly after issuing a certificate without arousing too much suspicion.
Maybe there is an acceptable way to shift long-term storage to CAs while using CT verifiers only for short term storage? E.g. they keep track of their last 30 days of signatures for a CA, which can then get cross-verified by other verifiers in that timeframe.
The storage requirements don't seem that bad though and it might not be worth any reduced redundancy and increased complexity for a different storage scheme. E.g. what keeps me from doing this is the >1Gbps and >1 pager requirements.
torbid
If CAs have to share CTs and have to save everything the CT would save to their last submission then no CA can destroy the log without colluding with other CAs.
(I.e. your log ends abruptly but polling any other CA that published to the same CT shows there is more including reasons to shut you down.)
I don't see how a scheme where the CT signer has this responsibility makes any sense. If they stop operating because they are sick of it, all the CAs involved have a somewhat suspicious looking CT history on things already issued that has to be explained instead of having always had the responsibility to provide the history up to anything they have signed whether or not some CT goes away.
michaelt
The point of CT logging is to ensure a person can ask "What certificates were issued for example.com?" or "What certificates were issued by Example CA?" and get an answer that's correct - even if the website or CA fucked up or got hacked and certificates are in the hands of people who've tried to cover their tracks.
This requires the logs be held by independent parties, and retained forever.
torbid
I understand that. But..
If 12 CAs send to the same log and all have to save up to their latest entry not to be declared incompetent to be CAs, how would all 12 possibly do a worse job of providing that log on demand than a random 3rd party who has no particular investment at risk?
(Every other CA in a log is a 3rd party with respect to any other, but they are one who can actually be told to keep something indefinitely because they would also need to return it for legitimizing their own issuance.)
michaelt
As far as I know, CAs don't have to "save up to their latest entry"
The info they get back from the CT log may be a Merkle Hash that partly depends on the other entries in the log - but they don't have to store the entire log, just a short checksum.
tonymet
Is any amateur or professional auditing done on the CA system? Something akin to amateur radio auditing?
Consumers and publishers take certificates and certs for granted. I see many broken certs, or brands using the wrong certs and domains for their services.
SSL/TLS has done well to prevent eavesdropping, but it hasn't done well to establish trust and identity.
sleevi
All the time. Many CA distrust events involved some degree of “amateurs” reporting issues. While I hesitate to call commenters like agwa an amateur, it certainly was not professionally sponsored work by root programs or CAs. This is a key thing that Certificate Transparency enables: amateurs, academics, and the public at large to report CA issues.
At the same time, it sounds like the issues you describe aren’t CA/issuance issues, but rather, simple misconfigurations. Those aren’t incidents for the ecosystem, although definitely can be disruptive to the site, but I also wouldn’t expect them to call trust or identity into disrepute. That’d be like arguing my drivers license is invalid if I handed you my passport; giving you the wrong doc doesn’t invalidate the claims of either, just doesn’t address your need.
Spivak
I think over the years trust and identity have gone out of scope for TLS—I think for the better. Your identity is your domain and it's not TLS's problem to connect that identity to any real life person or legal entity. I'm sure you still can buy EV certs but no one really cares about them anymore. Certainly browsers no longer care about them. And TLS makes no claim on the trustworthiness of the site you're connecting to, just that the owner of the cert proved control of the domain and that your connection is encrypted.
I can't even imagine how much a pain it would be to try and moderate certs based on some consistent international notion of trustworthiness. I think the best you could hope to do is have 3rd parties like the BBB sign your cert as a way of them "vouching" for you.
dboreham
Add an incentive mechanism to motivate runn a server, and hey it's a blockchain. But those have no practical application so it must not be a blockchain..
johnklos
> People: at least two. The Google policy requires two contacts, and generally who wants to carry a pager alone.
This is rich. Imagine a company that famously can't be contacted by humans wanting - no, expecting - to be able to reach someone at their leisure.
I'm sorry, but no. I'd consider running a CTL, but I'd never give contact information to the likes of Google unless I got the same in return.
johnklos
I suppose we've got a lot of Google fans here! Do you like not being able to contact anyone there? You could be a Youtube creator with a million followers and you'll never correspond with anyone with any control over anything at Google ;)
danpalmer
This just doesn't match my experience.
People love to say it, but when we had GSuite issues at my previous workplace we spoke to GSuite support and had a resolution quickly. When we had GCP queries we spoke to our account manager who gave us a technical contact who escalated internally and got us the advice we needed. When we asked about a particular feature we were added to the alpha stage of an in-development product and spoke with the team directly about that. I've got friends who have had various issues with Pixel phones over the years and they just contact support and get a replacement or fix or whatever.
Meanwhile I've seen colleagues go down the rabbit hole of AWS support and have a terrible time. For us it was fine but nothing special, I've never experienced the amazing support that I've heard some people talk about.
We were a <100 person company with a spend quite a bit less than many companies of our size. From what I've heard from YouTubers with a million followers, they have account managers and they always seem to encourage talking to account managers.
johnklos
But you're giving Google money.
I should've qualified what I wrote, but what I mean is that no matter who you are, if you don't know someone there and aren't paying them money, there's no way to communicate with humans there.
It's like companies that won't let you sign up unless you give them a cell phone number, but not only do they not have a number themselves, they don't even have email. Or, for companies like Verizon, they don't have email, but they have phone numbers with countless layers of "voice assistants" you can't skip. It's a new way of "communicating" that's just crazymaking.
null
null
null
null
Sunlight and static-ct-api are a breath of fresh air in the CT log space. Traditional CT log implementations were built on databases (because that's the easiest way to implement the old API) and were over-complicated due to a misplaced desire for high write availability. This made operating a CT log difficult and expensive (some operators were spending upwards of $100k/year). Consequentially, there have been a rash of CT log failures and few organizations willing to run logs. I'm extremely excited by how Sunlight and static-ct-api are changing this.