CT (Certificate Transparency)

CT (Certificate Transparency) #

The “Trust, but verify” proverb fits particularly well the WebPKI. Clients trust CAs to only issue certificates after they’ve performed the necessary verifications. But what if a CA makes a mistake or if someone manipulates a CA into issuing certificates for a domain you own?
You would certainly want to know about it, wouldn’t you?

That’s exactly what CT (Certificate Transparency) is for! Publicly trusted CAs are obliged to submit all certificates they issue to CT logs. CT logs are publicly auditable and cryptographically verifiable append-only data stores based on Merkle trees, which is the same technology that underpins the Bitcoin cryptocurrency. This system works because most web browsers only trust certificates submitted to CT logs.

This page provides a high-level overview of certificate transparency. Refer to https://certificate.transparency.dev/ for more information.

Origin #

Certificate transparency was designed to detect maliciously or mistakenly issued certificates. It has since evolved into a global database which contains all publicly trusted TLS web server certificates. This database is used for various purposes. For example, security and compliance researchers use it to discover malformed or non-compliant certificates issued by CAs.

Certificate transparency is standardized in RFC 6962. In 2024, its inventors were awarded the Levchin Prize, which honors major innovations in cryptography.

RFC 9162 proposes Certificate Transparency 2.0. But it is likely that this proposed new version will never be widely adopted.

Sunlight is an experimental addition to the Certificate Transparency 1.0 specification that optimizes the internals of CT logs and increases caching opportunities. The Sunlight specification defines new APIs for reading CT logs.

Domain Owner Responsibilities #

Site owners are supposed to monitor CT logs for certificates issued for their domains. If they find a certificate they did not request, site owners can contact the CA who issued it to request its revocation. The faster and simpler way is to revoke it via ACME.

Domain owners can use tools and services listed at https://certificate.transparency.dev/monitors/ to monitor certificates issued for their domains. In particular, https://crt.sh/ is very handy to discover certificates submitted to CT logs.

Your hostnames are not private !

Anyone can watch CT logs to discover (potentially internal/non-public) hostnames and newly turned up sites. Hostnames cannot be considered private!

If you rely on your internal hostnames to be secret to remain secure, first, just don’t. Security through obscurity is not a good strategy. Second, consider using a private CA to issue TLS web server certificates for your internal hosts if you want to ensure they won’t show up CT logs.

How does it work ? #

CAs must embed SCTs (Signed Certificate Timestamps) in certificates they issue 1. A SCT is a receipt signed by a CT log to attest it accepted the certificate. But there is a problem here. Since the certificate doesn’t exist yet, how can it be submitted to the CT log?

Precertificates to the rescue! A precertificate is a clone of a certificate with 3 key differences:

  1. It doesn’t include SCTs.
  2. It includes a critical CT poison extension, which is not recognized by any client (by design/on purpose). This ensures that the precertificate cannot be used instead of the real certificate.
  3. Its signature is different since it is not byte-for-byte identical to the certificate.

Here is an example precertificate and the corresponding certificate.

SCTs cannot be signed by any CT log. They must be signed by CT logs trusted/recognized by web browsers. In the same way that browsers only trust specific CAs, browsers also only trust specific CT logs. Here are the CT logs recognized by major browsers:

When browsers validate publicly trusted TLS web server certificates, they extract the SCTs and they verify their signature against their list of trusted CT logs. The signature verification doesn’t require connecting to the CT logs since browsers already know their public key.

CT logs are operated, for free, by a few organizations who believe this is the right thing to do for providing a safer Internet to everyone. They provide an invaluable service that most Internet users are not even aware of. Running reliable and compliant CT logs is expensive and requires a lot of work. Log operators deserve a large thank you (some accept donations!).

No publicly trusted CA can issue certificates if all CT logs stop working!

XKCD comic showing that the whole WebPKI relies on CT logs


  1. In reality, there are other ways to present SCTs to clients, but embedding them in certificates is by far the most common way to do it. See RFC 6962 for more information. ↩︎

acmeprotocol.dev is a side project from Fabien Hochstrasser. The opinions expressed on this website are my own and do not reflect the views of my current or former employers.