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 2013, Google discovered that a CA had issued unauthorized certificates for several Google domains. Technically valid — signed by a trusted CA. Could have been used for surveillance. Google caught it because they had certificate pinning deployed. Without that pin, nobody would have noticed.
The question that followed was obvious: how many other unauthorized certificates exist that nobody has caught?
The Answer: Make Everything Visible
Certificate Transparency, standardized in RFC 6962 and proposed by Google engineers, is built on a simple idea: every certificate issuance should be a public act.
CAs submit certificates to CT logs before or during issuance. The logs are publicly searchable. Anyone can look up every certificate ever issued 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) — cryptographic proof that the certificate was logged. The SCT is included in the certificate itself, or delivered via a TLS extension or OCSP stapling.
Browsers require SCTs. Chrome demands 2-3 SCTs from independent logs depending on the certificate’s validity period. A certificate without SCTs will be 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
CT logs contain every certificate issued for every domain by every publicly trusted CA. This 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.comreveals 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 followed the Let’s Encrypt playbook: 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 100+ CAs. 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.