Every publicly trusted TLS certificate is now expected to leave a public trail.

That is one of the best things the web ever did to itself.

Before Certificate Transparency, a certificate authority could issue a fraudulent certificate for your domain and, unless someone stumbled across it in use or the CA confessed, you might never know. The whole public PKI ecosystem depended on a strange mixture of trust and luck. If a CA misissued a cert in secret, detection was mostly accidental.

In 2011, attackers broke into DigiNotar, a Dutch certificate authority, and issued themselves more than 500 rogue certificates, including a wildcard for google.com. That certificate was technically valid — signed by a CA every browser trusted — and it was used to intercept Gmail traffic in Iran. It got caught because Chrome shipped with Google’s own keys pinned, so Chrome users hit an error and one of them reported it. Without that pin, there’s a good chance nobody would have noticed. DigiNotar was removed from every major browser and went bankrupt within weeks. (It happened again on a smaller scale in 2013, when an intermediate under France’s ANSSI minted Google certificates — again spotted by Chrome’s pins.)

The question that followed was obvious: how many other unauthorized certificates exist that nobody has caught? And the uncomfortable answer was that pinning only protects the handful of sites that a browser vendor bothers to pin.

The Answer: Make Everything Visible

Certificate Transparency, proposed by Google engineers Ben Laurie and Adam Langley and published as RFC 6962 in 2013, is built on a simple idea: every certificate issuance should be a public act.

In practice a CA submits a “precertificate” to CT logs just before issuing, though a certificate can also be logged afterwards. The logs are public. Anyone can look up every logged certificate for any domain. If a CA issues a certificate you didn’t authorize, CT is how you find out.

The system doesn’t prevent fraudulent issuance. It makes it visible. That distinction matters. CT doesn’t stop a compromised CA from minting a fake cert. It ensures the fake cert can’t hide.

How CT Logs Work

A CT log is an append-only data structure — specifically, a Merkle tree. Certificates can be added but never removed or modified. The tree structure means you can mathematically prove that a certificate is in the log, and you can prove that the log hasn’t been tampered with.

When a CA submits a certificate, the log returns a Signed Certificate Timestamp (SCT) — a signed promise that the certificate will be added to the log within a fixed window, usually 24 hours. If the log breaks that promise, the signature is the evidence. The SCT is included in the certificate itself, or delivered via a TLS extension or OCSP stapling.

Browsers require SCTs. Chrome has required them for certificates issued since April 2018, Safari followed, and Firefox started enforcing CT on desktop in version 135 in early 2025. Chrome wants two or three SCTs from logs run by different operators, depending on the certificate’s validity period. A certificate without them is rejected. This is the enforcement mechanism — CAs can’t skip logging because browsers will refuse to trust unlogged certificates.

Multiple independent logs exist, operated by different organizations — Google, Cloudflare, Let’s Encrypt, Sectigo, and others. Requiring SCTs from multiple independent logs means no single log operator can suppress a certificate’s visibility.

What You Can Find

Because browsers reject unlogged certificates, CT logs effectively contain every certificate a public CA has issued for use on the web. That includes:

  • Every subdomain. If a CA issues a cert for internal.staging.corp.example.com, it’s in the CT logs. Domain owners who use public CAs for internal infrastructure inadvertently expose their internal naming structure.

  • Every issuer. You can see which CAs issued certificates for your domain and when. If a CA you’ve never heard of issues a cert for your domain, that’s a red flag.

  • Historical records. CT logs are append-only, so they contain years of certificate history. You can see when certificates were issued, when they were renewed, and track changes over time.

This is why CT is both a security tool and a reconnaissance tool. Services like crt.sh provide free, searchable access to CT log data. Security teams use it to monitor their domains for unauthorized certificates. Attackers use it to discover subdomains for reconnaissance.

The dual use is a known tradeoff. The security community decided that the visibility benefits outweigh the subdomain disclosure risk. If your security depends on hiding your subdomain names, you have other problems.

The Privacy Tradeoff

Internal hostnames appearing in CT logs is a real concern for some organizations. Names like jenkins.internal.corp.example.com or vpn-staging.example.com reveal infrastructure details that were previously invisible.

The mitigation options:

  • Use a private CA for internal certificates. Private CAs don’t submit to CT logs. If your internal services don’t need public trust, they don’t need public certificates.
  • Accept the tradeoff. Subdomain names are often discoverable through other means — DNS enumeration, search engines, passive DNS databases. CT logs add another source but rarely the only one.
  • Use wildcard certificates for internal infrastructure. *.internal.example.com reveals less than individual subdomain certs. Though wildcards have their own security tradeoffs.

Monitoring: The Part Most Domain Owners Skip

CT logs enable domain owners to monitor for unauthorized certificates. If someone gets a cert for your domain from a CA you didn’t authorize — whether through compromise, social engineering, or a domain validation flaw — the cert shows up in CT logs.

Monitoring services exist. Google, Facebook, and other large organizations run their own CT monitoring. Smaller organizations can use free tools or paid services that alert on new certificate issuance for their domains.

Most domain owners don’t monitor CT logs at all. They don’t know the logs exist. They’ve never heard of crt.sh. The tool for catching unauthorized certificates is there. Most people haven’t picked it up.

Why CT Works

CT succeeded where many internet-wide security improvements haven’t because it ran the same play Let’s Encrypt later made famous: make the right thing automatic.

CAs are required to log. Browsers are required to check for SCTs. Domain owners can monitor but don’t have to — the enforcement happens without their involvement. The system works even if most domain owners never look at a CT log.

That’s good design. Security that requires everyone to participate doesn’t scale. Security that works by default, with optional monitoring for those who want it, actually gets deployed.

CT didn’t fix the trust model. Browsers still trust well over a hundred root certificates. Any one of them can still issue a cert for any domain. But CT means they can’t do it in secret. In a system built on trust, transparency is the next best thing to verification.