Update, August 18, 2025
We have updated the read-only and shutdown dates to ensure that our new Static CT API logs are fully trusted by browsers before switching Oak to read-only in order to avoid any disruption.
Let’s Encrypt operates two types of Certificate Transparency (“CT”) logs—some implement the original RFC 6962 API, and some that implement the newer Static CT API. Today we are announcing that on November 30, 2025, we will make our RFC 6962 logs read-only. Past that date, we will write only to our Static CT logs. On February 28, 2026, we will entirely shut down our RFC 6962 logs.
End users (consumers or relying parties) of Web PKI certificates do not need to take any action. The work that needs to be done to make this transition will be handled by Let’s Encrypt and the browsers.
RFC 6962 is from June of 2013 and describes the original version of CT. It was a revolutionary upgrade for transparency in the Web PKI, ultimately allowing anyone to monitor issuance from all certificate authorities. Over time, though, growth in certificate issuance volume has revealed that the original CT design doesn’t scale well enough. Let’s Encrypt currently issues more publicly trusted certificates in a single day than existed in total during 2013.
The first issue with RFC 6962 logs is the high cost of running them, particularly at Web scale, which has significantly limited the number of entities willing to operate them. Annual cloud costs for our logs are approaching seven figures.
The biggest contributor to this is that the data is stored in a relational database. We’ve scaled that up by splitting each year’s worth of data into a “shard” with its own database, and then later shrinking the shards to cover six months instead of a full year.
The approach of splitting into more and more databases is not something we want to continue doing forever, as the operational burden and costs increase. The current storage size of a CT log shard is between 7 and 10 terabytes. That’s big enough to be concerning for a single database: we previously had a test log fail when we ran into a 16 TiB limit in MySQL.
Scaling read capacity up requires large database instances with fast disks and lots of RAM, which are not cheap. We’ve had numerous instances of CT logs becoming overloaded by clients attempting to read all the data in the log, overloading the database in the process. When rate limits are imposed to prevent overloading, clients are forced to slowly crawl the API, diminishing CT’s efficiency as a fast mechanism for detecting mis-issued certificates. Ideally, clients should be able to obtain copies of the whole log in a relatively short time, but the traditional API has made that impractical.
The second issue with RFC 6962 logs is the potential for problems and non-compliance when the period called a Maximum Merge Delay (“MMD”) is exceeded.
One of the goals of CT was to have limited latency for submission to the logs. The Merge Delay design feature was added to guarantee that property. When receiving a new certificate submission, a CT log can return a Signed Certificate Timestamp (SCT) immediately, with a promise to include it in the log within the log’s MMD, conventionally 24 hours. While this seems like a good tradeoff to avoid the alternative of slowing down certificate issuance, there have been multiple incidents in which important logs have exceeded their maximum merge delay, breaking that promise.
If the log does not integrate the certificate within the MMD window, the log is out of compliance and can be distrusted. If a log is distrusted, it’s disruptive for the operators and those who depend on it, and there are fewer logs for the ecosystem to rely on.
In 2023 Filippo Valsorda suggested a new API for CT logs that avoids both of these issues—the Static CT API. The Static CT API for submitting certificates to logs is the same as RFC 6962, but the API for retrieving certificate information is quite different and the MMD is eliminated. The result is logs that are much more cost effective to operate and have better availability. We previously discussed our experiences testing out the new design in “Reflections on a Year of Sunlight.”
Certificate Transparency logs are a binary tree, with every node containing a hash of its two children. The “leaf” level contains the actual entries of the log: the certificates, appended to the right side of the tree. The top of the tree is digitally signed. This forms a cryptographically verifiable structure called a Merkle Tree, which can be used to check if a certificate is in the tree, and that the tree is append-only.
Static CT tiles are files containing 256 elements each, either hashes at a certain tree “height” or certificates (or pre-certificates) at the leaf level. Russ Cox has a great explanation of how tiles work on his blog, or you can read the relevant section of the Static CT specification.
Unlike the dynamic endpoints in the RFC 6962 API, serving a tree as tiles doesn’t require any dynamic computation or request processing, so we can eliminate the need for API servers. Because the tiles are static, they’re efficiently cached, in contrast with CT APIs like get-proof-by-hash, which have a different response for every certificate, so there’s no shared cache. The leaf tiles can also be stored compressed, saving even more storage!
The idea of exposing the log as a series of static tiles is motivated by our desire to scale out the read path horizontally and relatively inexpensively. We can directly expose tiles in cloud object storage like S3, use a caching CDN, or use a webserver and a filesystem.
Object or file storage is readily available, can scale up easily, and costs significantly less than databases from cloud providers. It seemed like the obvious path forward. In fact, we already have an S3-backed cache in front of our existing CT logs, which means we are currently storing our data twice.
Static CT takes a different approach to adding certificates to the log while maintaining the same external submission API as RFC 6962. Static CT logs hold submissions while it batches and integrates certificates in the log, eliminating the merge delay. While this leads to a small latency increase, we think it’s worthwhile to avoid one of the more common CT log failure cases.
It also lets us embed the final leaf index in an extension of our SCTs, bringing CT a step closer to direct client verification of Merkle tree proofs. The extension also makes it possible for clients to fetch the proof of log inclusion from the new static tile-based APIs, without requiring server-side lookup tables or databases.
Let’s Encrypt has submitted new Static CT API logs for inclusion in certificate transparency programs. We expect these logs to be included and trusted prior to the read-only date for our RFC 6962 logs, and we will begin submitting our certificates to them as soon as possible.
We may stop submitting our own certificates to our RFC 6962 logs prior to the read-only date, but other CAs will be able to write certificates to our RFC 6962 logs until the read-only date.
The Static CT API has proven to be operationally better and more scalable than the RFC 6962 design in almost every way. With the substantial increase in certificate volume over time, we need that improved efficiency to make running CT logs cost-effective. As a result, we’re switching fully to the new log architecture in order to make the best use of our resources. The Static CT API logs we operate will provide exactly the same security and transparency benefits as our old RFC 6962 log did.
As we explained above, this requires no changes at all for end users. It may require configuration changes on the part of certificate authorities that have been submitting certs to our old log (they can start submitting to one or both of our new logs instead). It also requires software updates for ecosystem participants who monitor logs; they’ll need to ensure that they have client software that’s compatible with the new API. Overall, this change should help ensure that our CT logging continues to be able to grow with the Web PKI.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。