Certificate Transparency: How CT Logs Secure the Web's PKI

Certificate Transparency (CT) is a public, append-only logging system that records every TLS certificate issued by a Certificate Authority (CA). Before CT existed, a CA could issue a fraudulent certificate for any domain — and nobody would know unless the victim happened to notice. CT changes this by requiring CAs to submit every certificate to multiple independent logs before browsers will trust it. Anyone can monitor these logs to detect misissued or unauthorized certificates for their domains.

CT was created by Google engineers Ben Laurie and Adam Langley in response to a series of devastating CA compromises. It is defined in RFC 6962 (and the updated RFC 9162 for CT v2) and has been mandatory in Chrome since April 2018. Today, every publicly-trusted TLS certificate must be logged in at least two CT logs, or browsers will reject it.

The Problem: Why CAs Alone Aren't Enough

The TLS certificate system relies on Certificate Authorities — organizations trusted by browsers to vouch for the identity of websites. When you visit https://example.com, your browser checks that the server's certificate was signed by a CA in its trust store. But this model has a critical weakness: any of the hundreds of CAs trusted by your browser can issue a certificate for any domain. A single compromised or negligent CA can undermine the security of the entire web.

Before CT, the only way to discover a misissued certificate was to stumble upon it — perhaps by noticing a certificate pinning failure or an unexpected connection warning. There was no systematic way for domain owners to know what certificates existed for their domains.

The Incidents That Forced Change

DigiNotar (2011)

In the summer of 2011, attackers compromised DigiNotar, a Dutch Certificate Authority. They issued over 500 fraudulent certificates, including one for *.google.com. Iranian users began seeing these fake certificates when accessing Gmail — the Iranian government was using them for mass surveillance via man-in-the-middle attacks. The compromise was only discovered because Chrome had implemented certificate pinning for Google domains, causing connection failures for affected users. DigiNotar was removed from all browser trust stores and went bankrupt within weeks.

Comodo (2011)

Months before DigiNotar, a Comodo registration authority was compromised, and fraudulent certificates were issued for login.live.com, mail.google.com, login.yahoo.com, and several other high-value domains. The attacker, later attributed to an Iranian individual, exploited weak authentication in Comodo's reseller infrastructure.

Symantec (2015-2017)

Google discovered that Symantec (the world's largest CA at the time) had misissued over 30,000 certificates, including unauthorized test certificates for domains like google.com. Symantec's CA infrastructure had such poor controls that they couldn't even provide a complete accounting of all certificates they had issued. Google gradually distrusted Symantec certificates in Chrome, forcing Symantec to sell its CA business to DigiCert in 2017.

Other Incidents

CNNIC (China Internet Network Information Center) issued an unauthorized intermediate CA certificate in 2015 that was used to generate certificates for arbitrary domains — discovered by CT log monitoring. TurkTrust accidentally issued two intermediate CA certificates to organizations that were supposed to receive regular end-entity certificates. ANSSI (France's government CA) issued a certificate for google.com for use in a network monitoring device. Each of these incidents demonstrated that the trust model was fundamentally fragile.

How Certificate Transparency Works

CT introduces three new components into the certificate ecosystem:

1. CT Logs

A CT log is a publicly accessible, append-only data structure that records certificates. Logs are operated by independent organizations — Google, Cloudflare, DigiCert, Sectigo, and others each run one or more logs. Key properties:

• Append-only — certificates can be added but never deleted or modified. This is enforced by a Merkle tree hash structure (the same data structure used in Bitcoin and other blockchains).
• Publicly auditable — anyone can query a log to enumerate all certificates it contains.
• Cryptographically verifiable — Merkle tree proofs let anyone verify that a certificate is included in the log without downloading the entire log, and that the log hasn't been tampered with.

When a CA submits a certificate (or precertificate) to a log, the log returns a Signed Certificate Timestamp (SCT) — a promise that the certificate will be incorporated into the log within a maximum merge delay (typically 24 hours). The SCT is signed by the log's private key and includes a timestamp and the log's ID.

2. Monitors

Monitors are services that watch CT logs for certificates of interest. Domain owners (or services acting on their behalf) run monitors to detect any certificate issued for their domains. If example.com sees a certificate appear in a CT log that they didn't request, they know something is wrong — either a CA was compromised or someone social-engineered a certificate issuance.

Major monitoring services include Google's transparency report, Facebook's CT monitoring (now Meta), Censys, and crt.sh (operated by Sectigo). Many CAs and CDN providers also offer monitoring to their customers.

3. Auditors

Auditors verify that CT logs are behaving correctly — that the log is append-only, that the Merkle tree is consistent, and that previously observed SCTs correspond to entries actually in the log. Browsers can act as lightweight auditors by checking SCTs during TLS connections.

Merkle Trees: The Data Structure Behind CT

CT logs use a Merkle hash tree to provide efficient, cryptographic proofs of inclusion and consistency. A Merkle tree is a binary tree where:

• Each leaf node contains the hash of a certificate entry
• Each internal node contains the hash of its two children concatenated
• The root hash (tree head) is a single hash that commits to the entire contents of the log

This structure enables two critical operations:

• Inclusion proof — given a certificate and the root hash, a log can provide a short proof (O(log n) hashes) that the certificate is contained in the tree. The verifier recomputes hashes up to the root and checks that it matches the signed tree head.
• Consistency proof — given two signed tree heads (from different points in time), the log can prove that the second tree is a strict extension of the first — no entries were removed or reordered. This is how auditors detect log misbehavior.

With billions of certificates in production CT logs, the Merkle tree structure keeps proofs compact: verifying inclusion of a certificate in a log with 4 billion entries requires only about 32 hashes.

SCT Delivery Methods

After a CA obtains SCTs from CT logs, these SCTs must be delivered to the browser during the TLS handshake so the browser can verify the certificate was logged. There are three mechanisms:

• X.509v3 extension — the CA embeds SCTs directly in the certificate as an extension (OID 1.3.6.1.4.1.11129.2.4.2). This is the most common method because it requires no changes to the server configuration. Let's Encrypt and all major CAs use this approach.
• TLS extension — the server sends SCTs in a TLS extension (signed_certificate_timestamp, type 18) during the handshake. This requires the server operator to fetch and configure SCTs, but allows SCTs to be updated without reissuing the certificate.
• OCSP Stapling — SCTs are included in the OCSP response that the server staples to the TLS handshake. This piggybacks on the existing OCSP infrastructure but requires the CA's OCSP responder to include SCTs.

In practice, the X.509 extension method dominates because it's transparent to server operators — the CA handles everything during issuance.

Browser Enforcement

Browsers are the enforcement point for CT. Without browser enforcement, CT would be a voluntary system with no teeth.

• Chrome — has required CT for all publicly-trusted certificates since April 30, 2018 (Chrome 68). Certificates without valid SCTs from at least two independent logs are treated as untrusted, showing the same error as an expired or self-signed certificate. Chrome maintains its own CT log list and has strict uptime requirements for log operators.
• Safari/Apple — requires CT for all certificates issued after October 15, 2018. Apple's policy requires SCTs from at least two logs operated by different organizations, and certificates valid for more than 180 days require SCTs from at least three logs.
• Firefox — has been slower to enforce CT but monitors CT logs extensively and uses CT data in its security research.

CT Log Lifecycle

CT logs are not permanent. They go through a defined lifecycle:

1. Pending — a new log has been submitted for inclusion in a browser's trusted log list and is under review.
2. Qualified/Usable — the log is trusted by browsers. CAs can submit certificates and the SCTs will be accepted.
3. Read-only — the log no longer accepts new certificates but continues to serve existing data and proofs. SCTs previously issued remain valid.
4. Retired — the log is no longer operated. Previously issued SCTs from this log may still be accepted by browsers during a grace period.

Google's Argon, Xenon, and Nimbus log shards are examples of temporal sharding — each shard only accepts certificates expiring within a specific time window. This keeps individual logs from growing unboundedly.

Precertificates

A subtle but important detail: CAs typically submit precertificates to CT logs rather than final certificates. A precertificate is identical to the final certificate except it contains a special "poison" extension (OID 1.3.6.1.4.1.11129.2.4.3) that makes it invalid for TLS authentication. This allows the CA to obtain SCTs before the final certificate is issued, then embed those SCTs in the final certificate's X.509 extension.

The flow is:

1. CA creates a precertificate (same key, same subject, plus poison extension)
2. CA submits precertificate to multiple CT logs
3. CT logs return SCTs
4. CA creates the final certificate with SCTs embedded in an X.509 extension
5. CA delivers the final certificate to the subscriber

Monitoring in Practice

The most immediately useful aspect of CT for domain owners is monitoring. By watching CT logs, you can detect:

• Unauthorized certificates — a CA issues a cert for your domain that you didn't request (CA compromise, social engineering, or domain validation bypass)
• Subdomain discovery — certificates reveal the existence of subdomains that may not be listed in public DNS (e.g., staging.internal.example.com)
• CA inventory — see which CAs are issuing certificates for your domains, useful for CAA (Certificate Authority Authorization) policy enforcement
• Phishing domains — attackers registering look-alike domains (e.g., examp1e.com) often obtain certificates for them, which show up in CT logs

The site crt.sh provides a searchable interface to CT log data. Searching for a domain shows every certificate ever logged for it, including issuer, validity dates, and SANs (Subject Alternative Names). Tools like Certstream provide a real-time firehose of newly logged certificates.

CAA Records: Complementing CT

While CT detects misissued certificates after the fact, CAA (Certificate Authority Authorization) DNS records prevent them proactively. A CAA record specifies which CAs are authorized to issue certificates for a domain:

example.com.  IN  CAA  0 issue "letsencrypt.org"
example.com.  IN  CAA  0 issuewild "letsencrypt.org"
example.com.  IN  CAA  0 iodef "mailto:[email protected]"

CAs are required (by the CA/Browser Forum Baseline Requirements) to check CAA records before issuing certificates. The iodef tag specifies where to report policy violations. CAA + CT together provide a defense-in-depth strategy: CAA tries to prevent misissue, and CT detects it if prevention fails.

CT and the BGP Connection

Certificate Transparency intersects with BGP security in several important ways:

• BGP hijacks enable domain validation bypass — many CAs validate domain ownership by connecting to the domain over HTTP or checking DNS records. An attacker who hijacks the BGP route for a domain's IP prefix can intercept these validation requests and obtain a fraudulent certificate. CT ensures that even if this succeeds, the certificate will be publicly visible in logs, enabling rapid detection and revocation.
• The MyEtherWallet BGP hijack (2018) combined BGP hijacking with DNS manipulation to redirect users to a phishing site. CT log monitoring was one of the signals that helped identify the attack.
• RPKI + DNSSEC + CT form a complementary security stack: RPKI secures the routing layer, DNSSEC secures DNS resolution, and CT secures certificate issuance. Each addresses a different link in the chain that connects a domain name to a verified TLS connection.

You can see these relationships in action by looking up ASNs of major CT log operators. Google operates CT logs from its infrastructure in AS15169, Cloudflare from AS13335, and DigiCert from AS14618 (AWS). The geographic and network diversity of CT log operators is itself a defense — compromising one log's network path doesn't affect others.

Limitations and Criticisms

CT is not a perfect solution:

• Detection, not prevention — CT detects misissued certificates after they are issued. The certificate may be used maliciously during the window between issuance and detection. CT reduces this window but cannot eliminate it.
• Privacy concerns — CT logs are public, which means every certificate (and thus every domain and subdomain) is discoverable. Organizations using internal subdomains like vpn.corp.example.com or payroll.internal.example.com have these names exposed. Some organizations use wildcard certificates to partially mitigate this.
• Log operator concentration — a small number of organizations (primarily Google and Cloudflare) operate the majority of trusted CT logs. If a major log operator goes down, CAs may struggle to obtain enough SCTs for browser compliance.
• Revocation lag — even when CT monitoring detects a fraudulent certificate immediately, revoking it takes time. CRL and OCSP infrastructure is notoriously unreliable, and some browsers soft-fail on revocation checks.
• No protection for private CAs — CT only covers publicly-trusted certificates. Private CAs used within enterprises are not required to log certificates, so internal misissue goes undetected.

CT v2 (RFC 9162)

RFC 9162, published in 2021, defines Certificate Transparency version 2 with several improvements over the original RFC 6962:

• Ed25519 signatures — support for modern signature algorithms alongside the original ECDSA and RSA
• Improved privacy for domain names — mechanisms for logging certificate metadata without revealing the full certificate in some configurations
• Better log lifecycle management — formalized temporal sharding and log state transitions
• Stronger consistency guarantees — tighter requirements for Merkle tree consistency proofs

Adoption of CT v2 is ongoing, with most production logs still running v1 implementations as of 2025.

Practical Impact

Since mandatory CT enforcement began in 2018, the certificate ecosystem has become dramatically more transparent:

• Over 10 billion certificates have been logged across all CT logs
• Let's Encrypt alone issues over 4 million certificates per day, all publicly logged
• Multiple CA compromises and misissues have been detected through CT monitoring, including the CNNIC incident and various smaller CAs issuing unauthorized certificates
• CT data has become a valuable resource for security researchers studying the certificate ecosystem, tracking phishing campaigns, and mapping internet infrastructure

Certificate Transparency transformed the web PKI from a system where trust was assumed to one where trust is verified. Combined with TLS, DNSSEC, and RPKI, it forms part of the layered security architecture that protects the modern internet — each layer addressing a different threat, from route hijacking to man-in-the-middle attacks to certificate fraud.