What is Certificate Transparency (CT)?

Certificate Transparency (RFC 6962) is an open cryptographic framework created by Google to monitor and audit SSL/TLS certificates. Public Certificate Authorities (CAs) are required to append every issued certificate to public, append-only, verifiable Merkle tree logs.

Why was Certificate Transparency created?

Historically, if a rogue or compromised CA (such as DigiNotar in 2011) issued a fake certificate for google.com or any other domain, the domain owner had no way of knowing. CT makes all SSL issuances publicly visible within seconds, enabling immediate detection of malicious or rogue certificates.

How do security researchers use CT logs for subdomain discovery?

Whenever an organization provisions an SSL certificate for an internal host (e.g. dev-api.company.com, vpn.company.com, staging.company.com), that hostname is permanently recorded in public CT logs. Security teams and bug bounty hunters query these logs to discover assets passively without sending any packets to the target.

Can a CA issue a certificate without logging it to CT?

Technically yes, but modern web browsers (Chrome, Safari, Firefox) mandate Signed Certificate Timestamps (SCTs) embedded in the certificate or TLS handshake. If a public certificate is not logged to at least two independent CT logs, browsers flag the connection as untrusted (ERR_CERTIFICATE_TRANSPARENCY_REQUIRED).

How can I search CT logs for my domain?

You can query CT logs in real time using our Certificate Transparency Search tool and Subdomain Finder, which index live CT streams without relying on slow third-party proxies.

Certificate Transparency (CT) Logs: Passive Subdomain Discovery & SSL Monitoring

In 2011, attackers compromised the Dutch Certificate Authority DigiNotar and issued hundreds of fraudulent wildcard SSL certificates for high-value targets, including *.google.com. Because browsers trusted the CA root, Iranian surveillance actors intercepted traffic for over 300,000 users without triggering any browser warnings. The domain owners were completely blind to the fact that counterfeit certificates had been minted in their name.

To eliminate this systemic vulnerability, Google introduced Certificate Transparency (RFC 6962). Today, every public TLS certificate issued worldwide must be cryptographically recorded in public, append-only ledgers. While designed for PKI security, CT logs have also become one of the most potent intelligence sources for passive reconnaissance and shadow IT discovery.

How Certificate Transparency Works Under the Hood

Certificate Transparency relies on three core components:

1. CT Log Servers (Cryptographic Merkle Trees)

CT logs are append-only public databases maintained by independent organizations (Google, Cloudflare, DigiCert, Let's Encrypt, Sectigo). They store certificates in Merkle Trees—cryptographic binary trees where every parent node is a hash of its children, culminating in a single root hash.

Append-only: Certificates can be added, but never modified or deleted.
Auditability: Anyone can verify the cryptographic consistency proof to ensure no records have been tampered with.

2. Signed Certificate Timestamps (SCTs)

When a CA receives a certificate request, it submits a pre-certificate to multiple CT log servers. The log server responds with an SCT (Signed Certificate Timestamp)—a cryptographic receipt promising that the certificate will be included in the public log within a fixed Maximum Merge Delay (typically 24 hours). The CA embeds this SCT directly into the issued X.509 certificate.

3. Browser Enforcement

When Google Chrome, Apple Safari, or Mozilla Firefox establishes a TLS connection, the browser inspects the certificate for valid SCTs from multiple independent CT logs. If SCTs are absent or invalid, the browser rejects the connection with ERR_CERTIFICATE_TRANSPARENCY_REQUIRED.

Passive Subdomain Discovery with CT Logs

Because every certificate issuance (including Let's Encrypt automated certbot runs, AWS ACM certificates, and Cloudflare Universal SSL) is published to CT logs, querying these logs reveals:

Staging & QA environments: staging.api.company.com, qa-auth.company.com
Internal infrastructure: vpn.corp.company.com, k8s-dashboard.company.com
Forgotten SaaS apps: zendesk-proxy.company.com, metabase.internal.company.com
Wildcard Subject Alternative Names (SANs)

The beauty of CT reconnaissance is that it is 100% passive. You do not send a single DNS query or TCP packet to the target's servers, leaving zero footprint in their firewall or WAF logs.

How to Monitor and Query CT Logs

1. Web-Based CT Log Search

You can search live CT issuances across all major global logs using our Certificate Transparency Search and enumerate all known subdomains with our Subdomain Finder.

2. Command-Line Exploration (crt.sh & CertSpotter)

Security engineers often query CT databases directly via cURL and JSON APIs:

# Query CertSpotter API for all issued certificates
curl -s "https://api.certspotter.com/v1/issuances?domain=example.com&include_subdomains=true&expand=dns_names" \
  | jq '.[].dns_names[]' | sort -u

Using CT for Defensive Security

Enterprise security teams use automated CT log alerting to:

Detect Rogue Issuance: Get notified instantly if an unauthorized third party orders an SSL certificate for your company brand.
Prevent Subdomain Takeover: Discover old subdomains pointing to abandoned CNAMEs (AWS S3, Heroku, GitHub Pages) before attackers hijack them.
Enforce CAA Records: Restrict which CAs can issue certificates in the first place using CAA Records.

Summary

Certificate Transparency transformed the internet from a closed trust model into a globally verifiable, auditable security ecosystem. To inspect your own domain's SSL health and live cipher suites, run a scan with our SSL Checker.