Certificate Transparency: How Merkle Logs Ended Blind Trust in CAs

TL;DR — Any of the world’s trusted certificate authorities can issue a TLS certificate for any domain — including yours — and for most of the web’s history nobody, including you, would ever know. Certificate Transparency (CT) ended that blind spot: every public certificate must be written to append-only, publicly auditable Merkle logs before browsers will trust it. The design turns CA misbehavior from an invisible event into a detectable one — and it has actually worked, catching a top-tier CA in 2015. Here’s how the logs, proofs and ecosystem fit together.

In September 2015, researchers found that Symantec’s certificate division had issued unauthorized “test” certificates for google.com and a string of other domains it did not own — YouTube, Gmail, apple.com, microsoft.com, linkedin.com, bankofamerica.com. The discovery channel mattered as much as the discovery: the certificates showed up in public Certificate Transparency logs, where anyone watching could see them. The episode escalated into Google’s phased removal of trust in Symantec’s roots (complete in Chrome 70, late 2018, after the certificate business was sold to DigiCert) — and it remains the canonical demonstration of why the web needed CT in the first place.

The Problem CT Solves

The TLS trust model is extreme federation: your browser trusts roughly a hundred certificate authorities, and every one of them can issue a certificate for any domain. If a CA is compromised, deceived, or merely sloppy, a forged certificate for your bank or your mail provider can be minted silently. Before CT there was no global record of issuance to compare against — a domain owner had no reliable way to learn that a certificate for their name existed at all. Security then depended on the hope that misissuance would be noticed by accident.

This is the same structural weakness we keep meeting on this site: unverifiable data from a trusted-but-unaccountable source. It’s the aviation position-broadcast problem from the ADS-B and GNSS spoofing piece, transplanted to PKI — the difference is that CT actually deployed a cryptographic fix at web scale. The fix has three parts: public append-only logs, proof-carrying certificates, and independent watchers.

The Merkle Log: Append-Only by Construction

A CT log — specified in RFC 6962 (2013) and its successor RFC 9162, “Certificate Transparency Version 2.0” (December 2020), which obsoleted it — is a single, ever-growing, append-only Merkle tree of submitted certificates and precertificates. Entries can be added; they can never be modified, deleted, or retroactively inserted, because every change to the tree would change the root hash. The log periodically signs and publishes that root as a signed tree head, cryptographically committing it to the entire history so far.

Two proof types make the structure usable rather than merely clever:

• Inclusion proofs. Given a signed tree head and a certificate, the log proves the certificate is in the tree by supplying the O(log n) sibling hashes along the path from leaf to root. A client re-hashes upward and checks the root — no need to download the whole log.
• Consistency proofs. Given an old tree head and a new one, the log proves the new tree is a pure extension of the old one — nothing rewrote history between the two snapshots. This is what lets independent auditors verify append-onlyness over time.

Around the logs, three roles keep the system honest:

SCTs: The Promise a Log Makes

The enforcement mechanism is the Signed Certificate Timestamp (SCT): the log’s signature over (roughly) “I, log X, promise to include this certificate by time T.” An SCT is delivered either embedded in the certificate itself as an extension, or out-of-band during the TLS handshake. The promise is checkable: if the log later refuses to serve an inclusion proof for a timestamped certificate, it has demonstrably broken its commitment.

Browsers turned this into hard policy on a staggered schedule:

The two-SCT requirement is deliberate redundancy: a certificate must be committed to by multiple independent log operators, so a single misbehaving or unavailable log can’t hide an issuance or hold the ecosystem hostage.

What It Caught — and What It Catches Now

The Symantec case is the headline, but the ongoing value is quieter and more routine. Facebook’s engineering team reported in CT’s early years that monitoring caught new certificates for their domains within about an hour of issuance — before the certificates were deployed anywhere — turning certificate abuse detection from forensics into a near-real-time control. The same mechanics power phishing defense today: typosquatting and lookalike domains need certificates, and each one is a public, searchable admission of infrastructure that would otherwise stay dark until first use. That’s why CT feeds naturally into a detection engineering pipeline: certificates are structured, timely telemetry, and monitoring them is a detection problem like any other.

CT also changed the economics of CA accountability. Misissuance that once surfaced by luck now surfaces in hours (GlobalSign and others describe detection times in hours rather than days or weeks), and the public record makes post-incident audits conclusive — either the logged history shows what a CA claims, or it doesn’t.

The Ecosystem Today

• Search: crt.sh, operated by Sectigo, has been the standard public CT search interface since 2013 — query by domain, watch the full issuance history of any name.
• Monitoring as a product: Cert Spotter, Cloudflare’s CT monitoring, and vendor equivalents alert domain owners when new certificates appear for their names.
• The v2 transition: Let’s Encrypt announced in August 2025 that its RFC 6962 logs would become read-only on November 30, 2025, with all issuance moving to its Static CT API logs built on RFC 9162 — the ecosystem’s concrete move off the 2013-vintage spec onto v2.
• OSINT and attack surface: security teams mine CT logs to enumerate subdomains and certificate names before attackers do — discovery that cuts both ways, since the logs serve defenders and reconnaissance alike.

Working With CT in Practice

• Monitor your domains. Pick a monitoring service (or poll crt.sh’s JSON API) for every name you care about, including lookalike variants; alert on anything you didn’t request. An unexplained certificate is a finding, not noise.
• Expect SCTs on everything you issue. If you operate your own CA or issue certificates via automation, verify your issuance path embeds SCTs from multiple accepted logs — browsers will refuse SCT-less certificates outright.
• Use CT for inventory. The logs are a free, global certificate inventory for your organization — frequently more current than internal CMDBs, and the fastest way to find forgotten wildcard certificates.
• Verify, don’t assume. When auditing a CA or your own issuance pipeline, check inclusion proofs against signed tree heads rather than trusting that “it’s probably logged” — the whole design exists so you don’t have to assume.

Key Takeaways

• The web’s CA model lets any trusted CA issue for any domain silently; CT makes every public issuance visible and permanently auditable.
• Logs are append-only Merkle trees (RFC 6962, superseded by RFC 9162 in December 2020); inclusion and consistency proofs let anyone verify membership and non-rewriting without downloading the log.
• SCTs are logged commitments carried by every modern certificate; Chrome has required them since April 30, 2018, Apple since October 15, 2019 with a minimum of two SCTs.
• CT detected the 2015 Symantec test certificates for google.com and underpinned the eventual distrust of its roots — proof the mechanism works against a major CA.
• Today CT powers near-real-time misissuance and phishing detection, certificate inventory, and attack-surface discovery; the ecosystem is migrating to RFC 9162 v2 logs (Let’s Encrypt’s 6962 logs went read-only November 30, 2025).
• Monitoring certificates for your domains is cheap, high-signal detection — treat an unexpected certificate as an incident candidate.

FAQ

What is Certificate Transparency?
A system of public, append-only Merkle-tree logs that record all publicly trusted TLS certificates, plus the proofs, signatures (SCTs) and monitoring ecosystem that make the records verifiable and useful.

Does CT stop certificates from being misissued?
No — it stops misissuance from being invisible. A rogue certificate still gets issued, but it must be publicly logged to work in browsers, where the legitimate domain owner (or anyone) can find it within hours.

What is an SCT?
A Signed Certificate Timestamp: a log’s signed promise to include a specific certificate by a deadline. Browsers require SCTs on newly issued certificates — embedded in the cert or delivered during the TLS handshake.

What’s the difference between RFC 6962 and RFC 9162?
RFC 6962 (2013) was the experimental original; RFC 9162 (December 2020) is the v2 standard that obsoletes it, with a cleaner Merkle structure (Static CT API logs). Major operators have been moving issuance to v2 logs — Let’s Encrypt finalized its transition in November 2025.

How do I check certificates issued for my domain?
Search crt.sh for your domain, or subscribe to a CT monitoring service that alerts on new issuance — including subdomains and lookalikes.

Can certificates be removed from CT logs?
No. Logs are append-only by cryptographic construction; that permanence is the feature. (This also means logs contain only public certificate data — not private keys — and there are established processes for handling accidentally logged secrets elsewhere in PKI.)

References

1. RFC 9162 — Certificate Transparency Version 2.0 (obsoletes RFC 6962)
2. RFC 6962 — Certificate Transparency (original, 2013)
3. certificate.transparency.dev — How CT Works
4. certificate.transparency.dev — Monitors
5. crt.sh — Certificate search (operated by Sectigo)
6. Let’s Encrypt — End of life plan for RFC 6962 CT logs
7. EFF — Symantec issues rogue EV certificate for google.com (2015)
8. Apple — Certificate Transparency policy requirements
9. Chromium — CT policy documentation (GitHub)
10. Google — Symantec certificate distrust timeline in Chrome

Current as of September 2026. Educational engineering reference — for certificate policy questions, follow the current Chromium and Apple CT program documents.

Published by Hmmnm

Hands-on cybersecurity tutorials, CVE breakdowns, and guided learning paths — written and lab-tested by the Hmmnm team.

Learning Paths · About Hmmnm · Editorial policy