What CT is

Certificate Transparency is an ecosystem of append-only, publicly auditable logs of TLS certificates. Whenever a participating CA issues a certificate, it submits that certificate to one or more CT logs, which in return hand back a Signed Certificate Timestamp (SCT) — a cryptographic promise that the certificate will appear in the log.

The original specification is RFC 6962 (2013). The current standardised form is RFC 9162 (2021).

Browsers require every publicly trusted TLS certificate to come with valid SCTs from at least two qualified logs operated by independent organisations. Without them, the certificate is rejected at the handshake.

Why CT exists

Before CT, certificate misissuance was invisible. A compromised or malicious CA could issue a certificate for google.com and nobody at Google would know unless they stumbled across it. The 2011 DigiNotar incident — a Dutch CA compromised by an attacker who issued certificates for Google, Mozilla, and the CIA — was the catalyst. The CA had been compromised for weeks before anyone noticed.

CT inverts the model: every issuance is immediately public. Domain owners (and automated monitors) can watch CT logs for certificates issued for their domains that they didn't request — immediate signal of misissuance. Attackers can no longer issue a cert for example.com without example.com's operators learning about it within seconds.

How CT works

Log structure

A CT log is an append-only Merkle tree. New certificates are appended; the tree's root hash is signed periodically. Monitors can verify both that nothing has been removed and that specific entries are present.

Each log is operated by a specific organisation — Google, Cloudflare, DigiCert, Sectigo, Let's Encrypt all operate logs — with specific availability, consistency, and retention commitments.

The issuance flow

CA receives a CSR. After normal validation (CAA, DCV, etc.) the CA mints a pre-certificate (an almost-cert with a poison extension so it's not accepted by TLS clients).
CA submits the pre-cert to multiple CT logs. Each log returns a Signed Certificate Timestamp (SCT) — a signed timestamp + promise the cert will be incorporated in the log.
CA issues the final certificate with the SCTs embedded, either in an X.509 extension, as an OCSP response alongside the cert, or in a TLS extension at handshake time.
TLS clients verify the SCTs during the handshake, rejecting certs that don't have SCTs from the expected number of qualified logs.

Monitoring

Anyone can query a CT log. Common monitors:

crt.sh — Sectigo's public CT monitor
Censys — enterprise-grade monitoring
Google's CT logs browser
Internal corporate monitors fed by a subscription

For a domain owner, the right setup is: subscribe to alerts on any new certificate issued for your domains. If a cert appears that you didn't request, something is wrong.

What CT caught (and why it matters)

Symantec misissuance (2015-2017). CT monitoring surfaced thousands of misissued Symantec certificates. The resulting distrust by Google and Mozilla pushed Symantec to sell its CA business to DigiCert.
StartCom / WoSign backdating (2016). CT showed certificates with issuance timestamps that pre-dated their appearance in logs — the CA was backdating to bypass policy. Both CAs were distrusted.
eMudhra (2026). The eight single-byte-private-key intermediates were discovered by a researcher querying CT logs for recently-issued intermediates and running automated public-key health checks.

Without CT, each of these would have remained undiscovered or been detected much later with much larger damage.

CT and Multi-Perspective Issuance Corroboration

CT is the detection side of the "CA misbehaviour" problem. MPIC is the prevention side — it makes BGP-hijack domain-validation attacks harder. The two complement each other.

CT log lifecycle

CT logs have finite lifetimes. A log operator can "sunset" a log — stop accepting new entries — while keeping the existing entries readable. New certificates must get SCTs from currently-active logs. The Chrome Root Program and Mozilla both maintain lists of qualified logs with validity windows.

Enterprise CAs and CT monitoring pipelines need to track log rotation — a certificate chain that only includes SCTs from retired logs may fail validation in future browser versions.

What CT does not do

Does not prevent misissuance. A CA can still issue bad certificates. CT ensures they're visible — not that they can't happen.
Does not trigger automatic revocation. CT monitors can alert on unexpected issuance, but the CA has to actually revoke.
Does not apply to private PKI. Internal CAs issuing to internal workloads generally don't log to public CT.
Does not validate SCTs cryptographically beyond the log signature. If a log is compromised, the log can emit valid SCTs for cert entries it's lying about. Browsers mitigate by requiring SCTs from multiple independent logs.

Certificate Transparency