On February 28, 2026, Let’s Encrypt shut down Oak — the Certificate Transparency log that, for years, recorded a large share of the certificates issued on the public internet. Three months earlier, on November 30, 2025, it had gone read-only. If you’re a CA, a browser, or someone who monitors certificates for your domains, this was a big deal. If you’re everyone else, nothing happened, because the thing that replaced Oak had already been running quietly beside it.
What replaced it is the interesting part. Certificate Transparency used to run on one of the most operationally demanding pieces of infrastructure in the whole Web PKI: a live, append-only cryptographic database that browsers required you to keep online, consistent, and answering queries around the clock. The replacement is a directory of static files sitting in an object-storage bucket. That sounds like a downgrade. It is the opposite.
What CT Logs Do, and Why They Were Painful
The reason every certificate is public is that certificate authorities kept mis-issuing. The 2011 DigiNotar breach — where an attacker got a CA to issue a working certificate for Google’s domains — proved that you couldn’t just trust CAs to be careful, because a single compromised one could forge a certificate for anyone. Certificate Transparency, standardized as RFC 6962 in 2013, is the fix: every publicly trusted certificate has to be submitted to public, append-only logs, so that anyone — a domain owner, a researcher, a browser vendor — can watch what’s being issued in their name and catch a rogue certificate after the fact. Since 2018, Chrome has refused to trust a certificate that doesn’t come with cryptographic proof it was logged.
The security idea is elegant. The implementation was a beast.
An RFC 6962 log is a single, ever-growing Merkle tree, and the standard makes the log operator promise something hard: when a CA submits a certificate, the log immediately hands back a signed timestamp — an SCT — that promises the certificate will be merged into the tree within a fixed window called the Maximum Merge Delay, conventionally 24 hours. From then on the log has to serve, from a live queryable API, arbitrary inclusion proofs (“prove this specific certificate is in the tree”) and consistency proofs (“prove the tree only ever grew, never rewrote history”), and it has to keep publishing a signed tree head no older than that merge delay.
That is a distributed-systems problem wearing a cryptography costume. You’re running a database that can never lose an entry, never fork its history, never fall behind its own 24-hour promise, and never go down long enough for a browser to notice — because if it does, the browsers can distrust it. And they have. More than one CT log has been dropped from the trusted set after failing to keep its merge-delay promise, and distrusting a log is disruptive for everyone who was relying on it. The job of running a compliant CT log became known as one of the least enjoyable in the PKI: high stakes, high availability, unglamorous, and easy to fail.
The Rebuild: Serve the Tree, Don’t Query It
Here’s the insight that unwound all of that. A Merkle tree is already a stack of hashes. If you stop trying to answer clever questions about it from a live service, and instead just publish the whole thing as files, the hard part evaporates.
That’s the Static CT API — “static-ct-api” — and the implementation that made it real is Sunlight, designed and written by the cryptographer Filippo Valsorda in partnership with Let’s Encrypt and introduced in March 2024. A static log keeps the exact same submission side as before: a CA POSTs a certificate, gets an SCT back. But the read side is completely different. Instead of a live API that computes proofs on demand, the log publishes its tree as a hierarchy of static files called tiles — concatenated runs of consecutive Merkle tree hashes at fixed heights — plus a signed checkpoint. You serve those tiles from S3, or a CDN, or any dumb file host. Monitors download tiles and compute the proofs themselves.
Look at what that deletes. There’s no live proof-serving API to keep responsive under load. There’s no database that can fork. Object storage gives you the durability and availability for free — making a file available in a bucket is a problem Amazon solved a long time ago. And the Maximum Merge Delay, the 24-hour sword hanging over every operator, is simply gone from the model; the tree state is whatever the latest published checkpoint says it is. The append-only, publicly-auditable security property survives intact — it was always in the Merkle tree, not in the API in front of it. Only the operational misery got removed.
The cost numbers make the point bluntly. Valsorda has described running a production Sunlight log on a single server for on the order of $10,000 a year. Compare that to standing up a globally redundant, always-consistent, always-online cryptographic database that browsers will yank your trust over if it hiccups. This is the difference between infrastructure you dread and infrastructure you forget you have.
It Actually Shipped
The reason this reads as history rather than a proposal is that the switchover already happened, on the timeline that matters: browser trust. Chrome added static-ct-api to its CT policy in its early-2025 update (Chrome 134), Apple followed for Safari, and through 2025 the new static logs earned their place in the browser log programs — the qualification that lets a certificate’s SCTs from those logs actually count. Let’s Encrypt stood up its own static logs, Sycamore and Willow, and ran them beside Oak until the new ones were fully trusted. Only then did it announce the end of the old world: Oak read-only in November 2025, gone in February 2026.
That sequencing is the whole reason nothing broke. You do not turn off the log that a decade of certificates depend on until the replacement is trusted by the browsers those certificates have to satisfy. So the old and new ran in parallel, the trust moved over quietly, and the shutdown was an anticlimax by design.
The Boring Kind of Win
I keep coming back to how unglamorous this is, because that’s the point. The most successful protocol migration in the Web PKI in years wasn’t a new cryptographic primitive or a clever attack defense. It was someone looking at an expensive, fragile, always-on service and realizing the same security guarantee could be delivered by publishing static files — cheaper, more reliable, and easier for a small operator to run without a pager.
There’s a real trade-off worth naming: the monitoring side had to change. If you built tooling that asked a live CT log questions, it now has to fetch and walk tiles instead. That’s genuine migration work for the people who watch the logs. But it buys something the old design couldn’t: because a static log is just files, running one — and independently checking one — is now cheap enough that you don’t need to be Google to participate. A transparency system whose whole purpose is distributed, independent observation works better when observing it isn’t a privilege reserved for the few organizations that can afford the infrastructure.
The lesson isn’t “static is always better.” It’s that a lot of what makes infrastructure painful is accidental — a demanding live API standing in front of data that didn’t need one. Certificate Transparency spent a decade as a hard system to operate. It turned out the hard part was never the security. It was the plumbing, and the plumbing was optional.