The impetus for Certificate Transparency (CT) was a real incident. In 2011, DigiNotar, a Dutch Certificate Authority, was compromised. Attackers issued fraudulent TLS certificates for domains including Google.com, which Iranian ISPs used to intercept HTTPS traffic — a man-in-the-middle attack against dissidents using Google services. DigiNotar's certificate store was compromised for months before anyone detected it, because there was no public record of what certificates the CA had issued.
Certificate Transparency, formalized in RFC 6962 and later RFC 9162, was Google's answer to this: a requirement that all publicly trusted TLS certificates be submitted to independently operated, publicly auditable logs before browsers will trust them. Chrome has required CT compliance since April 2018. Safari has required it since October 2018. Today, any certificate issued by a browser-trusted CA must appear in at least two CT logs to be trusted.
How CT Logs Work
A Certificate Transparency log is a cryptographically verifiable, append-only data structure — specifically a Merkle hash tree. Entries can be added but never removed or altered. The structure makes it mathematically provable that:
- A specific certificate was or was not in the log at a specific point in time
- No entries have been deleted or silently modified since a given Signed Tree Head (STH) was published
- Log operators cannot create a private fork of the log for selected viewers
When a CA issues a certificate, it submits the certificate (or a pre-certificate, before final signing) to one or more CT logs. The log returns a Signed Certificate Timestamp (SCT) — a cryptographic proof that the certificate has been logged. This SCT is embedded in the certificate itself, delivered via TLS extension, or stapled via OCSP. Browsers verify the presence of valid SCTs; a certificate without them is rejected.
Google, Cloudflare, DigiCert, Sectigo, Let's Encrypt, and several other organizations operate CT logs that meet Chrome's inclusion criteria. Google's Chrome Root Program publishes the list of approved logs. The logs themselves are publicly readable — anyone can download and query the full log contents.
What CT Logs Expose About Your Infrastructure
Here is what any person with internet access can learn about your domains from CT logs:
- Every subdomain you've ever issued a certificate for, including internal staging environments, pre-launch products, VPN gateways, and development infrastructure — as long as you used a publicly trusted CA
- Exact issuance timestamps for every certificate, revealing when infrastructure was set up
- Certificate lifecycle: renewals, replacements, and expirations that reveal operational patterns
- Which CA you use and what validation type (DV, OV, EV)
- The Subject Alternative Names (SANs) on each certificate — every domain the cert covers
The reconnaissance value of this is significant. Before launching a targeted attack, an adversary can use tools like crt.sh (run by Sectigo), censys.io, or Certstream (a real-time feed of CT log entries) to build a near-complete map of your attack surface — including infrastructure you consider non-public — without ever touching your servers.
CT logs are the internet's public land registry for TLS certificates. They serve a vital security function, but if you're issuing certificates for internal services using a public CA, that infrastructure is catalogued and searchable.
The Subdomain Enumeration Problem
DNS subdomain enumeration used to require active techniques — brute-forcing common names, doing zone transfers if the nameserver misconfiguration allowed it, or running DNS amplification scans. CT logs changed the economics of this entirely.
A query for *.example.com on crt.sh returns every certificate issued for that domain's subdomains. This is fully passive — no packets ever reach your infrastructure. Bug bounty hunters use this routinely to find forgotten staging environments with weaker security postures. Attackers use it for the same reason.
The practical implication: if you issue TLS certificates for internal services (mail.internal.example.com, vpn.example.com, jenkins.example.com) using a publicly trusted CA, those names are in the CT logs forever. They're not accessible from the internet, but their names are now known. Combined with other intelligence — IP ranges from ASN records, port scanning, credential leaks — subdomain names from CT logs contribute to a detailed reconnaissance picture.
Wildcard Certificates: Partial Mitigation
A wildcard certificate covers *.example.com and exposes only that pattern in CT logs, not the individual subdomain names. This is a meaningful privacy improvement if your primary concern is subdomain enumeration.
| Approach | CT Log Exposure | Trade-offs |
|---|---|---|
| Per-subdomain certificates | Every subdomain name logged individually | Easier to manage revocation; subdomains are fully enumerable |
| Wildcard certificate | Only *.example.com logged |
Single cert covers all subdomains; single compromise affects all |
| Private CA (internal only) | Nothing logged publicly | Requires distributing CA cert to all clients; no browser trust by default |
| Multi-SAN certificate | All SANs logged in one entry | All domain names in the cert are still visible; no hiding individual names |
For truly internal infrastructure that should never be resolvable from the public internet, the correct approach is a private CA — a certificate authority you operate yourself, whose root certificate you distribute to internal clients. Certificates from a private CA are not submitted to public CT logs, because they're not using a publicly trusted root. Internal TLS without public CT exposure is straightforward with tools like CFSSL, step-ca, or a Vault PKI secrets engine.
Monitoring Your Own Certificate Log Entries
CT logs are not just an exposure vector — they're also a detection mechanism. If an attacker compromises a CA or conducts a supply-chain attack to get a fraudulent certificate issued for your domain, that certificate must appear in CT logs to be trusted by browsers. You can monitor CT logs for any new certificate issuance covering your domains.
Tools for this include:
- crt.sh email notifications: Set up an account on crt.sh and configure alerts for your domains
- Certstream: A real-time websocket feed of CT log entries; write a filter against your domains
- Facebook's Certificate Transparency Monitoring (ct.facebook.com): Email alerts for domains you verify ownership of
- Let's Encrypt's CT monitoring: ACME-based certificate issuance includes hooks for certificate lifecycle events
This is a worthwhile defense for any organization that cares about someone impersonating their domains. A fraudulent cert for mail.yourcompany.com used in a spear-phishing campaign would appear in CT logs within minutes of issuance — before most users ever see the phishing email.
The Connection to Certificate Pinning
Certificate pinning and CT solve related but distinct problems. CT tells you that a certificate exists and was properly logged; pinning tells your client application exactly which certificate or CA to trust. Together, they significantly constrain what a rogue CA can do: a fraudulently issued cert shows up in CT logs (enabling detection) and won't be trusted by a pinning-aware application (preventing exploitation).
For high-security applications — encrypted messaging clients, financial apps, infrastructure tooling — pinning plus CT monitoring is the appropriate combination. Neither alone provides complete protection; both together raise the cost of certificate-based attacks substantially.
The key operational takeaway: CT logs are a public, permanent record. Treat any certificate you issue with a publicly trusted CA as infrastructure intelligence that is, by definition, publicly known. Design your internal/external boundary accordingly — private CA for anything internal, public CA for anything that needs browser trust.