Certificate Transparency: How CT Logs Prevent Rogue Certificates

The certificate authority system is built on trust. When your browser connects to a bank's website and sees a green padlock, it's trusting that the certificate was issued by a recognised Certificate Authority — Let's Encrypt, DigiCert, Sectigo, Google Trust Services — and that the CA verified the requester actually controls the domain before signing the cert. There are about 100 publicly trusted root CAs in modern browser stores, and any one of them can issue a valid certificate for any domain.

That setup has an obvious failure mode. If a CA is compromised, or coerced by a government, or just makes a mistake, they can quietly issue a fake certificate for a domain they have no business signing. Before Certificate Transparency, the only way a domain owner could find out this had happened was if someone happened to notice — usually long after the damage was done. CT turned that on its head by making every issuance public, append-only, and cryptographically verifiable. Today, if a CA issues a certificate, the world knows within minutes.

The problem CT was built to solve

Two incidents made the case for CT impossible to ignore:

• DigiNotar, 2011. A Dutch CA was breached by an attacker who issued more than 500 fraudulent certificates, including one for *.google.com that was actively used to intercept Iranian Gmail users for weeks before anyone noticed. By the time the breach was understood, the certificates were already in the wild; the only fix was for browsers to distrust the entire CA, which they did. DigiNotar went bankrupt within weeks.
• Symantec misissuance, 2015–2017. Symantec — at the time one of the largest CAs in the world — was found to have repeatedly issued certificates without proper validation, including test certificates for domains they didn't control. Each individual incident was small; the pattern was systemic. By 2018, Google had distrusted every Symantec-issued cert in Chrome, forcing the world's largest CA operation to wind down and be sold for scraps.

Both incidents shared a structural problem: nobody outside the CA had any way to see what certificates had been issued. Google engineers Ben Laurie and Adam Langley proposed Certificate Transparency in 2012 as a fix. The premise was simple: require every CA to publish every certificate to a public log, force browsers to refuse certificates not present in those logs, and let domain owners (and anyone else) read the logs to detect issuance they didn't authorise. RFC 6962 standardised the protocol in 2013; Chrome made CT mandatory for all newly-issued certificates in April 2018; Apple and Mozilla followed.

How a CT log actually works

A CT log is a public, append-only data structure — specifically a Merkle hash tree — that any CA can submit certificates to and any client can read. The signing infrastructure is similar to a blockchain's, minus the distributed consensus: there are a few dozen logs run by different operators (Google, Cloudflare, DigiCert, Sectigo, Let's Encrypt, and others), each independently maintaining its own tree, and each tree is cryptographically chained so that entries can be added but never silently removed or modified.

The issuance flow has five steps:

• 1. CA submits the certificate. Before (or during) issuance, the CA POSTs the leaf certificate to one or more logs.
• 2. Log returns a Signed Certificate Timestamp. The log replies with an SCT — a signed promise to include the cert in the next tree update, within a stated time window (the log's "maximum merge delay," usually 24 hours).
• 3. CA embeds the SCT in the certificate. The SCT is bundled into the cert as an X.509 extension, or delivered alongside the cert during TLS via a separate handshake message (TLS extension or stapled OCSP response).
• 4. Browser verifies the SCT. When a client receives the certificate, it checks the SCT signature against the log's known public key. Chrome requires SCTs from at least two independent logs for every cert issued after April 2018.
• 5. Anyone reads the log. Any client can query the log for entries — there are public APIs and aggregators like crt.sh that index across many logs at once. Our CT search tool queries crt.sh and pretty-prints the results.

The cryptography is what makes the log "transparent" rather than just public. Because the tree is append-only, an attacker who compromises a log operator can't quietly remove an entry — doing so would invalidate every signed tree head ever published. Independent monitors continuously fetch consistency proofs between log snapshots to verify that the log is behaving honestly. If a log misbehaves, browsers can distrust it and force re-issuance of every cert that depended solely on it.

The killer use case: subdomain discovery

An unintended consequence of CT — and the reason security people love it — is that the logs are a comprehensive map of public web infrastructure. Every certificate carries the Subject Alternative Name (SAN) list of every hostname it's valid for. Search a CT log for %.example.com and you get every subdomain that has ever appeared on a publicly trusted certificate.

For a randomly picked target, the results are usually illuminating in ways the domain owner didn't intend. A typical search might surface:

example.com
www.example.com
staging.example.com
admin.example.com
vpn.example.com
internal-api.example.com
old-jenkins.example.com
forgotten-marketing-site.example.com
*.dev.example.com

Each of those is a hostname that has been put on a publicly trusted certificate at some point — which usually means it pointed at a real service, at least for a while. admin.example.com is the obvious example: a forgotten admin panel that should never have been on the public DNS. old-jenkins.example.com is the Jenkins CI server someone spun up for a one-off migration two years ago and never decommissioned. The wildcard *.dev.example.com is shorthand for "we use this for development hostnames; ask DNS what's there now."

Security researchers and bug-bounty hunters search CT logs as routine reconnaissance. Defenders use the same searches against their own domains to discover infrastructure they've forgotten about or services they didn't realise had been exposed. Either way, the CT log search is one of the highest-signal sources of attack-surface inventory available — for free, with no scraping, with no API key, and with no rate limit beyond what crt.sh's own server can handle.

CT for security monitoring

Beyond subdomain discovery, the other useful thing you can do with CT is monitor your own domain for unauthorised issuance. If someone — a malicious CA, a compromised employee account, an attacker who phished a CA's domain validation — gets a certificate issued for your domain from a CA you don't use, CT logs will show it within hours.

This is the reactive half of the certificate-authority defence-in-depth strategy. The proactive half is CAA records — a DNS mechanism that tells CAs "only this list of CAs may issue certificates for my domain." A well-configured domain has both: a tight CAA policy (the lock on the door) and CT monitoring (the alarm that goes off if someone picks the lock anyway). The CAA record lookup tool reads your domain's policy and grades the configuration.

Several services automate CT monitoring — Facebook has a free dashboard, Cloudflare and Google operate their own monitors for their hosted domains, and a number of commercial offerings (Hardenize, Mozilla Observatory, SSLMate) will email you when a new cert appears. For one-off audits, the CT search tool is enough: paste the domain, see every cert ever logged, deduplicated and ranked by date, with an issuer breakdown.

Reading a CT search result

A typical CT search returns one row per (deduplicated) certificate. The interesting fields are:

• Issuer — the CA that signed the certificate. If you see a CA you don't use anywhere in your stack, that's a red flag.
• Common Name and SANs — the hostnames the cert is valid for. New hostnames you didn't expect are the subdomain-discovery payoff.
• Not Before / Not After — issuance and expiry dates. A certificate that expired six years ago is harmless for current attackers but interesting as a historical record of infrastructure that used to exist.
• Serial number — a unique identifier per CA. Mostly useful for correlating across log entries.
• Wildcards — entries like *.example.com. These cover any single-level subdomain but don't reveal which hostnames have actually been used.

A few caveats worth being upfront about:

• Expired certificates are still in the log. CT is append-only. A cert issued in 2017 that expired in 2018 still appears in 2026 results. You can filter by date, but don't be alarmed if a search returns a hundred years-old entries — that's history, not exposure.
• Revoked certificates are still in the log. Revocation is a separate mechanism (CRL or OCSP). CT logs the issuance; revocation is logged elsewhere.
• Wildcards hide individual subdomain names. A cert for *.example.com doesn't tell you which subdomains have actually been deployed under that wildcard — only that something has been.
• Internal-only domains don't appear. If your team uses an internal CA (self-signed, a private intermediate, etc.) to issue certs for internal.example.com, those certificates don't go to any public log. CT only covers the publicly trusted CA ecosystem.
• HTTP-only sites don't appear. No cert, no CT entry. If a service runs without TLS, it's invisible to CT discovery (though it shouldn't be running without TLS in the first place).

How CT changed the certificate ecosystem

The biggest knock-on effect of CT, besides catching rogue issuance, has been to fundamentally change how CAs behave. Pre-CT, mis-issuance was something a CA could quietly fix without anyone outside ever knowing. Post-CT, every mistake is public and indexable. A CA that issues bad certs faces immediate, public scrutiny — and given that browser-level distrust is the death penalty for a CA's business, the discipline has been transformative. Modern CAs run automated checks, audit trails, and incident-response processes that would have been almost unimaginable in 2010.

CT also enabled Short-Lived Certificates as a practical pattern. Let's Encrypt's 90-day cert (and Google's 90-day, soon-to-be-shorter plans) only make sense if you can verify every renewal was logged. CT is the underlying machinery that makes the "issue, log, deploy, expire" cycle auditable at internet scale.

If you operate a domain, three things are worth doing this week. Search CT for your apex domain — every couple of months — to find subdomains you forgot about. Configure a tight CAA policy so attackers can't issue from arbitrary CAs in the first place. And inspect the current certificate the way a visitor's browser does it, with our SSL inspector. The combination — discovery via CT, prevention via CAA, ongoing inspection via SSL — is the most cost-effective certificate-security posture available to any domain owner.