Certificate Transparency explained for devs

The plain-English explanation of Certificate Transparency logs — what they contain, who runs them, and why they matter for every domain you own or ship code to.

If you have ever wondered how someone can list every subdomain a company owns without ever hitting their DNS — or how you would find out that a certificate authority (CA) issued a cert for your domain that you did not request — the answer is Certificate Transparency. It is the closest thing the web has to a public ledger of TLS-adjacent identity events, and it is required infrastructure for every publicly-trusted certificate issued since April 2018.

This article walks through what CT actually is, how the log architecture works, what a CT log entry contains, and the day-to-day operational uses that make CT worth understanding even if you never touch a certificate authority yourself.

Why Certificate Transparency exists

Certificate Transparency was proposed by Ben Laurie, Adam Langley, and Emilia Kasper at Google in 2013 in response to a series of misissuance incidents. In particular, in 2011 DigiNotar was compromised and issued rogue certificates for *.google.com that were then used against Iranian users; DigiNotar was subsequently distrusted by every major browser and went bankrupt within months (Mozilla security blog).

The design goal of CT is straightforward: make certificate misissuance detectable, not just preventable. If every certificate a browser trusts has to appear in a public log, then the certificate you did not ask for cannot hide from you.

The mechanism was standardized as RFC 6962 in June 2013 and superseded by the version-2 draft draft-ietf-trans-rfc6962-bis. Since April 2018, Chrome requires that every publicly-trusted certificate be accompanied by evidence of inclusion in at least two independent CT logs, or the certificate is rejected — the “CT Policy” enforcement described in the Chrome CT policy documentation. Apple (Safari CT policy) enforces a similar requirement in Safari.

How a CT log is structured

A CT log is an append-only Merkle tree of certificate entries. That sounds like buzzword bingo but is actually a small idea: each new entry is hashed together with the running head of the tree, producing a “signed tree head” (STH) that proves the log has not been rewritten. The full model is documented in RFC 6962 §2.

The three actors are:

• The CA that issues a certificate. Before the cert is used, the CA submits it (or, more commonly, a pre-certificate) to one or more CT logs.
• The log operator — historically Google, Cloudflare, Let’s Encrypt, DigiCert, Sectigo, and TrustAsia among others. The log operator signs a Signed Certificate Timestamp (SCT) proving the certificate was accepted.
• The client — usually a browser — verifies that the certificate it is about to accept carries valid SCTs from qualified logs.

What a CT entry actually contains

A single CT log entry is the DER-encoded X.509 certificate (or pre-certificate) plus the log’s signed metadata. When you fetch a log entry through the log’s get-entries API described in RFC 6962 §4.6, you get back the raw certificate; from there you extract:

• Subject — the identity the cert was issued to. For domain-validated (DV) certs this is usually just the common name.
• Subject Alternative Names (SANs) — every DNS name the cert covers. This is the field that makes CT so useful for reconnaissance and inventory: if your CA issued a cert for internal.dev.example.com, that hostname is now public.
• Issuer — the CA that issued the cert.
• Not-before and not-after — the validity window. Since March 2026, publicly-trusted certificates are capped at 200 days (CA/Browser Forum Ballot SC081v3), down from the previous 398-day cap.
• Serial number — unique per CA, stable per cert.
• SHA-256 fingerprint — the identity most tools index on.

What CT does not tell you

CT is deliberately narrow. It tells you a certificate was issued. It does not tell you:

• Whether the certificate is currently in use. Certificates can be issued and never deployed, or deployed and revoked. Revocation is tracked via CRL or OCSP, not CT.
• What IP or CDN the domain resolves to. For that you need DNS.
• Whether the certificate is trusted by every browser. Some certificates end up in CT logs and are still distrusted for other reasons (name constraints, incorrect key type, path length).

Practical operational uses

The interesting thing about CT is that once you accept the constraint that every publicly-trusted certificate must be logged, a set of operational habits becomes possible:

Domain inventory

Query CT for every certificate issued to a domain you own. You get an authoritative list of subdomains that had certificates issued — usually a superset of the subdomains you thought were in production. The CT lookup tool on this site is one way to do this; the canonical open-source tool is crt.sh, operated by Sectigo.

Misissuance detection

Set up a nightly job that queries CT for your domain and diffs against a last-known-good set of certificate fingerprints. Any unknown fingerprint is a lead — usually a benign cert issued by another team in your org, occasionally a legitimate misissuance you need to report to the CA.

Vendor and supply-chain due diligence

Look up the CT history for a vendor’s domain before you sign a contract. A vendor whose CT history is dozens of certificates from three CAs, expiring on different cadences, with a mix of DV, OV, and EV, is probably running an ad-hoc PKI. That does not mean don’t sign — it means know what you are signing.

Subdomain enumeration for security research

Bug-bounty and offensive-security researchers use CT as their first-choice reconnaissance tool because it is authoritative and read-only. There is no scan traffic, no rate limit worth speaking of, and no way for the target to detect the query. Guidance from the OWASP Web Security Testing Guide suggests CT as a standard reconnaissance step.

Common gotchas

Pre-certificates vs. certificates. When a CA submits to a CT log before the certificate is issued, they submit a pre-certificate — a not-yet-signed certificate with a poison extension. CT logs return both pre-certs and final certs, so counts can look doubled. The CT log monitoring guide from Cloudflare walks through this in more detail.

Certificate authority migrations. When a CA is distrusted or a company switches CAs, cert counts spike and pattern changes. That is normal, not an incident.

CT is not GDPR-exempt. Because SANs can include email-address hostnames (rare but legal) or first-name-lastname subdomains that identify an individual, CT contains personal data. The European Data Protection Board opinion on CT is that public interest outweighs the individual privacy risk, but it is worth being aware of if your domain naming convention exposes employee identities.

How Control Plane Labs uses CT

Two tools on this site are backed by CT data:

• The CT lookup tool, which returns the full CT history for a hostname sourced from CertIndex.
• The TLS certificate inspector, which parses the certificate returned by a live TLS handshake against a hostname.

If you want the underlying data programmatically, the CertIndex API is documented at ctindex.io/docs and offers a generous free tier for occasional lookups plus paid tiers for continuous monitoring.

The bottom line

Certificate Transparency is one of the quiet successes of modern web infrastructure. It has effectively eliminated the class of misissuance attacks that motivated its creation. It has also become one of the most useful sources of read-only asset intelligence anyone can query — which cuts both ways, so if you are running a domain, be aware that every certificate you issue is public, and configure your naming accordingly.

Read next

• How to use CT logs to find every subdomain a company owns
• Why your ACME renewal quietly broke last month
• Try the tool: CT lookup

Tags: #tls, #certificate-transparency, #security, #acme