up:: Classical Cryptography MOC

Certificate Transparency

Certificate Transparency is a system of public, append-only, cryptographically verifiable logs that record every TLS certificate a certificate authority issues, so that a mis-issued or fraudulent certificate can be spotted publicly instead of going unnoticed. Each log is built on a Merkle tree, which lets anyone confirm that a specific certificate was logged and that the log never quietly rewrote its own history. The logs don’t stop a CA from issuing a bad certificate; they make every issuance visible to the domain owners, browsers, and researchers who watch, so silent mis-issuance gets caught. Certificate Transparency was defined by RFC 6962 in 2013 and revised as Certificate Transparency Version 2.0 in RFC 9162 in 2021, and current versions of Chrome require it for every publicly-trusted certificate.

Source: B. Laurie, A. Langley, E. Kasper, “Certificate Transparency,” RFC 6962, June 2013, RFC 6962.

The short version:

1. Certificate Transparency (CT) is a set of public, append-only logs that record every issued TLS certificate, so mis-issuance by a CA becomes publicly detectable.
2. Each log is a Merkle tree, which gives two cheap guarantees: anyone can prove a certificate is in the log, and anyone can prove the log never deleted or altered a past entry.
3. When a certificate is logged, the log returns a Signed Certificate Timestamp (SCT), the log’s signed promise to add the certificate within a set time called the Maximum Merge Delay.
4. Browsers require a valid SCT before they trust a public certificate, which is what forces CAs to log everything they issue.
5. The PQC angle is that a log signs its SCTs and tree heads with ECDSA or RSA, both broken by Shor’s algorithm, so those signatures must migrate to post-quantum algorithms, and CT-style Merkle log infrastructure is the template behind scale approaches like Merkle Tree Certificates.

Think of Certificate Transparency as a giant public notary ledger for ID cards. Every time an issuing office prints a new ID card (a certificate), it has to write that card into a shared ledger that everyone can read and nobody can erase a page from. If a crook bribes one office into printing a fake card in your name, the card still has to be written into the ledger to be honored, and the moment it lands there, a watchdog reading the ledger sees a card issued in your name that you never asked for. The ledger doesn’t stop the office from printing the fake, and it guarantees the forgery can’t stay hidden, which is usually enough to get the office caught and the card revoked fast.

What is Certificate Transparency?

Certificate Transparency is an open framework for logging, auditing, and monitoring the TLS certificates that certificate authorities issue. RFC 6962 states its goal plainly: to “mitigate the problem of misissued certificates by providing publicly auditable, append-only, untrusted logs of all issued certificates,” so that “anyone” can “audit certificate authority (CA) activity and notice the issuance of suspect certificates.”

The problem it solves is structural to public key infrastructure. A browser trusts hundreds of certificate authorities, and any one of them can issue a certificate for any domain on the internet. Before CT, a CA that was compromised or coerced could issue a certificate for a domain it had no business vouching for, use it to impersonate that site, and the real domain owner would have no way to find out. CT closes that blind spot by making issuance a matter of public record. It doesn’t add a new gatekeeper deciding who gets a certificate, and it adds a public audit trail so that any issuance can be seen after the fact.

Three properties define a CT log:

1. Append-only. Entries are only ever added, never removed or edited. Once a certificate is in the log, it stays, in the same position, forever.
2. Cryptographically verifiable. The log is a Merkle tree, so its append-only behavior and the presence of any entry can be checked with math. Anyone can verify the log’s claims independently instead of trusting the operator’s word.
3. Publicly auditable. The logs are open. Domain owners, browser vendors, and independent researchers all read them, which is what makes mis-issuance detectable in practice.

Source: B. Laurie, A. Langley, E. Kasper, “Certificate Transparency,” RFC 6962, §1, June 2013, RFC 6962.

How does Certificate Transparency work?

Certificate Transparency works by inserting a logging step into the life of every certificate and then requiring proof of that step before a browser will trust the certificate. The flow runs in five moves:

1. A CA logs the certificate. Before or just after issuing, the CA submits the certificate (or a precertificate, a to-be-issued version) to one or more CT logs. RFC 6962 uses a precertificate carrying a special critical “poison” extension so it can’t be mistaken for a usable certificate while it’s being logged ahead of issuance.
2. The log returns an SCT. The log adds the submission to its Merkle tree and immediately returns a Signed Certificate Timestamp, its signed promise to include the entry within the Maximum Merge Delay. See the SCT section below.
3. The SCT travels with the certificate. The certificate then presents its SCTs to browsers during the TLS handshake. RFC 6962 defines three ways to deliver them, so a CA or server can pick whichever fits its setup.
4. The browser checks the SCTs. A CT-enforcing browser refuses to trust a publicly-issued certificate unless it arrives with valid SCTs from qualifying logs. Google’s policy states that in CT-enforcing versions of Chrome, “all publicly-trusted TLS certificates are required to be CT Compliant to successfully validate,” and certificates that aren’t “will simply fail to validate.”
5. Watchers audit the logs continuously. Monitors read the logs looking for certificates issued for domains they care about, and auditors check that the logs are behaving honestly. This is the step that actually catches mis-issuance.

The delivery mechanisms in move 3 are worth pinning down, because they decide how CT fits into an existing deployment without reissuing anything unusual:

SCT delivery method	How it works	When it’s used
X.509v3 certificate extension	The SCTs are embedded directly inside the certificate by the CA at issuance	The most common method; nothing changes on the server
TLS extension	The server sends SCTs in a TLS handshake extension, separate from the certificate	Lets a server add CT without the CA embedding anything
OCSP stapling	The SCTs ride along in a stapled OCSP response	Used where the server already staples revocation status

Source: B. Laurie, A. Langley, E. Kasper, “Certificate Transparency,” RFC 6962, §3, June 2013, RFC 6962.

What is a Signed Certificate Timestamp (SCT)?

A Signed Certificate Timestamp is the log’s signed promise to include a submitted certificate in its Merkle tree within a fixed window called the Maximum Merge Delay (MMD). RFC 6962 describes the SCT as “the log’s promise to incorporate the certificate in the Merkle Tree within a fixed amount of time known as the Maximum Merge Delay (MMD),” and specifies that when a valid submission arrives, “the log MUST immediately return a Signed Certificate Timestamp.”

The SCT matters because it’s the piece a browser actually checks. A certificate without valid SCTs fails validation in a CT-enforcing browser, so the SCT is the mechanism that forces a CA to log what it issues. If the CA skips logging, it gets no SCT, and without an SCT the certificate doesn’t work in Chrome. That’s the whole enforcement loop in one object.

Two related signed objects complete the picture:

1. The Signed Tree Head (STH). Every time the log adds entries, it signs the new Merkle root and tree size, producing a Signed Tree Head. The STH is the log’s signed statement of “this is exactly what my tree looks like right now,” and it’s what auditors and monitors check their proofs against.
2. The Maximum Merge Delay. The MMD is the ceiling on how long the log may take to actually merge a promised entry into the tree. It exists so an SCT is a binding promise with a deadline, not an open-ended IOU. A log that issues an SCT and fails to merge the entry by the MMD has provably misbehaved.

Source: B. Laurie, A. Langley, E. Kasper, “Certificate Transparency,” RFC 6962, §3, June 2013, RFC 6962.

How do Merkle trees make Certificate Transparency verifiable?

Certificate Transparency rests on the Merkle tree because a Merkle tree gives exactly the two guarantees CT needs, cheaply and without trusting the log operator. Each log is one append-only Merkle tree whose leaves are the logged certificates and whose single root (the Merkle root) is a fingerprint of the entire log. Any change to any entry changes the root, so the root, signed in each STH, pins down the whole log at a point in time.

Two proofs do the verification work:

1. Inclusion proof. Anyone can prove a specific certificate is in the log using a short chain of sibling hashes rather than downloading the entire log. RFC 9162 specifies that a CT log implements “a single, append-only Merkle Tree” and defines the inclusion proof as “the shortest list of additional nodes in the Merkle Tree required to compute the Merkle Tree Hash for that tree.” The proof grows only with the logarithm of the log size, so proving membership in a log of hundreds of millions of certificates still takes only a few dozen hashes. The exact bound and the mechanics live in the Merkle tree note.
2. Consistency proof. Anyone can prove that a newer version of the log is an append-only extension of an older version, meaning no earlier entry was removed or altered and only new leaves were added. This is what enforces the append-only promise. If a log ever tried to rewrite its history, it couldn’t produce a valid consistency proof between the two states, and the tampering would be caught.

Because the whole structure is built from a cryptographic hash function alone, the log’s integrity guarantees inherit directly from the strength of that hash, which is SHA-256 in the base standard. This is also the reason the tamper-evidence survives the quantum transition even though the log’s signatures don’t, a split the PQC section below pulls apart.

Source: B. Laurie, E. Messeri, R. Stradling, “Certificate Transparency Version 2.0,” RFC 9162, §2, December 2021, RFC 9162.

What do monitors and auditors do?

Monitors and auditors are the two watching roles that turn a passive log into an actual detection system, and they check different things. RFC 6962 defines both, and RFC 9162 keeps the monitor role central.

Role	What it does	What it catches
Monitor	Watches logs, inspects every new entry, and looks for certificates of interest, such as any certificate issued for a domain it protects	An unexpected or fraudulent certificate issued for a domain the monitor watches
Auditor	Takes partial information about a log and verifies it’s consistent with other partial information, using inclusion and consistency proofs	A log that misbehaves, by hiding an entry it promised or rewriting its history

In practice, a domain owner (or a service acting for one) runs monitoring to get alerted the instant a certificate is issued for their domain that they didn’t request. That alert is the payoff of the whole system: the fraudulent certificate is now known, and it can be reported and revoked quickly instead of being used to impersonate the site indefinitely. Auditing is the complementary check that keeps the logs themselves honest, so a compromised or malicious log can’t quietly cover for a mis-issuance.

Source: B. Laurie, A. Langley, E. Kasper, “Certificate Transparency,” RFC 6962, §5, June 2013, RFC 6962.

Why does Certificate Transparency matter?

Certificate Transparency matters because it removed the single largest blind spot in web PKI: the fact that any one of the many trusted certificate authorities could issue a certificate for any domain, silently. CT converts that silent power into a public, permanent record, which changes the incentives for every CA. A CA can still mis-issue, and now every issuance shows up where the affected domain owner and the whole security community can see it.

The reason CT is near-universal today is browser enforcement. Google’s Chrome CT policy requires that “all publicly-trusted TLS certificates are required to be CT Compliant to successfully validate,” and certificates that aren’t compliant “will simply fail to validate in CT-enforcing versions of Chrome.” Once the dominant browser refuses to trust an unlogged certificate, logging stops being optional for any CA that wants its certificates to work, so essentially every publicly-trusted certificate is now logged. That’s why CT is one of the load-bearing pillars of modern web trust rather than a nice-to-have.

It’s also the flagship real-world deployment of the Merkle tree. The same append-only, proof-backed log structure that keeps CAs honest is the structure being reused to make certificate issuance scale in the post-quantum world, which is where the quantum transition enters the story.

Source: Google, “Chrome Certificate Transparency Policy,” Chrome CT Policy.

How does the quantum transition affect Certificate Transparency?

The quantum transition hits Certificate Transparency in one specific place: the signatures the logs make. It leaves the log’s core integrity structure alone. Pulling those two apart is the whole story, and it mirrors the split in certificates generally.

1. The log’s signatures are quantum-vulnerable. A CT log signs its SCTs and its Signed Tree Heads with a digital signature algorithm. RFC 6962 specifies these as elliptic-curve signatures on the NIST P-256 curve (ECDSA) or RSA signatures, both of which Shor’s algorithm breaks on a cryptographically relevant quantum computer. A forged log signature would let an attacker fabricate SCTs or misrepresent the state of a log, so these signing keys have to migrate to post-quantum signatures such as ML-DSA.
2. The Merkle tree itself survives. The append-only log structure is built only from a hash function, and hashing is the part of cryptography that carries through the quantum era, dented only by Grover’s algorithm and restored by a large enough digest. So the inclusion and consistency proofs that make CT tamper-evident keep working unchanged. The exposure is the signatures wrapped around the tree, and the tree.

RFC 9162 already built the on-ramp for this. Version 2.0 added hash and signature algorithm agility through IANA registries, meaning a log can adopt a new signature algorithm without a redesign of the protocol, exactly the crypto-agility that a clean post-quantum migration depends on. RFC 9162 notes that a log supporting a new algorithm would keep the old one alongside it for backward compatibility, which is the standard staged-migration pattern.

The deeper connection runs the other way too. CT proved that a public, append-only Merkle-tree log can hold the entire world’s certificate issuance and stay verifiable at scale. That same infrastructure is the model behind Merkle Tree Certificates, a proposed approach that leans on CT-style logs to keep post-quantum certificates from ballooning the size of every TLS handshake. CT is both a thing that has to migrate and a piece of the machinery that makes the wider migration affordable.

Sources: B. Laurie, A. Langley, E. Kasper, “Certificate Transparency,” RFC 6962, §2.1.4, June 2013, RFC 6962.

B. Laurie, E. Messeri, R. Stradling, “Certificate Transparency Version 2.0,” RFC 9162, §1.2, December 2021, RFC 9162.

Common misconceptions

1. “Certificate Transparency prevents bad certificates from being issued.” It doesn’t. RFC 9162 is explicit that “the logs do not themselves prevent misissuance,” and they make it detectable so it can be caught and revoked. CT is a detection and accountability system, not a gate on issuance.
2. “CT logs are a blockchain.” They aren’t. A CT log is a single append-only Merkle tree run by a log operator, with its integrity checked by public proofs. There’s no chain of blocks, no consensus mechanism, and no distributed ledger.
3. “The logs are trusted authorities.” RFC 6962 calls them “untrusted logs” on purpose. The point of the Merkle-tree proofs is that you verify the log’s behavior mathematically rather than trusting the operator, and auditors exist precisely to catch a log that misbehaves.
4. “An SCT proves the certificate is legitimate.” An SCT only proves the certificate was submitted to a log and the log promised to include it. It says nothing about whether the certificate should have been issued. The legitimacy check happens when a monitor watching that domain sees the entry and flags it.
5. “CT makes certificate contents secret.” The opposite is true. CT publishes every issued certificate in the open, which is the whole mechanism. A certificate’s contents are public by design anyway, since a certificate carries only a public key and an identity, never a private key.
6. “Certificate Transparency is quantum-safe because it’s built on hashes.” Half right. The Merkle-tree log structure is quantum-safe, and the signatures the log makes over SCTs and tree heads use ECDSA or RSA, which a quantum computer breaks, so those still have to migrate.

Questions people ask

What is the difference between RFC 6962 and RFC 9162? RFC 6962 (2013) is the original experimental Certificate Transparency specification. RFC 9162 (2021) is Certificate Transparency Version 2.0, which obsoletes it and adds hash and signature algorithm agility through IANA registries, switches precertificates to CMS objects, and refines the log APIs and data structures. Both are Experimental-track RFCs, and the deployed ecosystem today largely reflects the 6962 design with the v2 improvements rolling in.

Who runs the CT logs? Log operators run them, including large organizations such as Google, Cloudflare, DigiCert, and Let’s Encrypt/Sectigo. Browser root programs decide which logs they’ll trust, and a certificate generally needs SCTs from more than one independently operated log to be considered compliant, so no single operator is a point of trust.

Does every website use Certificate Transparency? Effectively every publicly-trusted TLS certificate does, because current versions of Chrome refuse to validate a public certificate without valid SCTs. Privately-issued certificates from an internal enterprise CA that isn’t in the public trust stores aren’t required to be logged.

How does a domain owner benefit from CT? By monitoring the logs, a domain owner gets alerted the moment any certificate is issued for their domain, including one they never requested. That early warning is what lets them report and revoke a fraudulent certificate quickly instead of discovering the impersonation after damage is done.

Is Certificate Transparency the same as certificate revocation? No. Revocation (through CRLs or OCSP) is the mechanism for declaring an already-issued certificate invalid. CT is the mechanism for making issuance publicly visible so you know a bad certificate exists in the first place. They’re complementary: CT helps you find the fraudulent certificate, and revocation is how you then kill it.

Do CT logs store private keys? Never. A CT log stores certificates, which contain only public keys and identity information. The private key stays with the certificate’s owner and is never submitted anywhere, so a CT log carries nothing confidential.

Will Certificate Transparency need to change for post-quantum? Yes, in the signing layer. The logs sign SCTs and tree heads with ECDSA or RSA, which move to a post-quantum signature like ML-DSA, and RFC 9162’s algorithm agility is what makes that migration a configuration change rather than a redesign. The Merkle-tree structure underneath stays as it is.

What is a Maximum Merge Delay? It’s the maximum time a log is allowed to take between issuing an SCT (its promise to log a certificate) and actually merging that certificate into its Merkle tree. It turns the SCT into a promise with a deadline, so a log that hands out an SCT and never merges the entry within the window has provably broken its commitment.

---

Everything here is the map, given freely. When your team needs its own certificate and log-signing infrastructure found, sized, and sequenced onto a post-quantum path before the machine arrives, that’s the work I do. Request an alignment briefing.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.