Certificate Transparency Logs Explained

Certificate Transparency (CT) is a system of public, append-only logs that record every SSL/TLS certificate issued by participating certificate authorities. It was created to make certificate issuance visible and auditable, so that domain owners and the broader internet community can detect misissued or fraudulent certificates. Before CT existed, a certificate authority could issue a certificate for your domain without your knowledge, and you would have no practical way to find out. For background on how SSL/TLS certificates work, see our SSL/TLS guide.

Why Certificate Transparency Was Created

CT was born out of real incidents where certificate authorities issued certificates they should not have.

In 2011, a Dutch certificate authority called DigiNotar was compromised. Attackers used DigiNotar's systems to issue fraudulent certificates for Google, Yahoo, Mozilla, and hundreds of other domains. These certificates were used to intercept encrypted communications in Iran. The breach was only discovered when a user in Iran noticed a certificate warning in Chrome. DigiNotar was subsequently distrusted by all major browsers and went bankrupt.

In 2015, Symantec-affiliated CAs issued unauthorized test certificates for Google domains. Google discovered this through CT logs, which by then were partially deployed. This incident eventually led to Symantec's entire CA business being distrusted by Chrome and other browsers.

These incidents exposed a fundamental weakness in the CA system: there was no mechanism for domain owners to know what certificates existed for their domains. A compromised or negligent CA could issue certificates quietly, and the only detection method was stumbling upon them by chance.

Google proposed Certificate Transparency in 2013 as a solution. The idea was simple: make every certificate issuance a public, auditable event.

How Certificate Transparency Works

The CT system has three main components: logs, monitors, and auditors.

CT Logs

CT logs are append-only, cryptographically verifiable data structures (based on Merkle trees) operated by various organizations. When a certificate authority issues a certificate, it submits the certificate (or a precertificate) to one or more CT logs. The log returns a Signed Certificate Timestamp (SCT), which is a promise that the certificate will be added to the log within a specified time period (the Maximum Merge Delay, typically 24 hours).

The append-only property is critical. Once a certificate is logged, it cannot be removed or modified. The Merkle tree structure makes it mathematically verifiable that the log has not been tampered with. Anyone can verify the integrity of the log at any time.

Signed Certificate Timestamps (SCTs)

The SCT is proof that a certificate has been submitted to a CT log. SCTs are delivered to browsers in one of three ways:

1. Embedded in the certificate (most common). The CA obtains SCTs from CT logs during the issuance process and embeds them as a certificate extension.
2. TLS extension. The server provides SCTs during the TLS handshake via the signed_certificate_timestamp TLS extension.
3. OCSP stapling. SCTs are included in the OCSP response that the server staples to the TLS handshake.

Monitors and Auditors

Monitors watch CT logs for certificates issued for specific domains. Domain owners (or services acting on their behalf) can monitor CT logs to detect unauthorized certificates. If someone obtains a certificate for your domain from any publicly trusted CA, it will appear in the CT logs.

Auditors verify that CT logs are behaving correctly: that they are append-only, that they are not omitting certificates, and that the cryptographic proofs are valid.

Google Chrome's CT Requirements

Chrome has required Certificate Transparency for all publicly trusted certificates since April 2018. To be trusted by Chrome, a certificate must be accompanied by SCTs from a sufficient number of CT logs.

The specific requirements are:

• Certificates with a validity period of less than 15 months need SCTs from at least 2 independent CT logs.
• Certificates with longer validity periods need SCTs from at least 3 independent logs.
• The logs must be operated by different log operators (to prevent a single operator from colluding with a CA).

If a certificate does not meet these requirements, Chrome will show an error and will not establish a trusted connection. This effectively mandates CT compliance for any CA that wants its certificates to work in Chrome.

Apple's Safari and other Apple platforms have similar CT requirements. Firefox does not enforce CT as strictly but has expressed support for the system.

How to Search CT Logs

Several tools let you search CT logs to find certificates issued for any domain.

crt.sh

The most widely used CT log search tool is crt.sh, operated by Sectigo. You can search by domain name and see every certificate that has been logged for that domain, including the issuing CA, validity dates, and the full certificate details.

Search for %.yourdomain.com to find certificates for your domain and all subdomains. The % wildcard matches any subdomain prefix.

Google's Certificate Transparency Search

Google operates a CT log search at transparencyreport.google.com/https/certificates. It searches Google-operated CT logs and provides similar information to crt.sh.

Certstream

Certstream is a real-time feed of certificates being added to CT logs. It is useful for monitoring new certificate issuance in real time rather than searching historical logs.

Monitoring Your Domain for Unauthorized Certificates

CT logs make it possible to detect when someone obtains a certificate for your domain without your authorization. This could indicate a compromised CA, a domain validation bypass, or an attacker who gained temporary control of your DNS.

CT and the Certificate Lifecycle

CT logs record certificates at issuance time. This has several practical implications for how you manage your certificates.

Pre-certificates vs final certificates. CAs often submit a "precertificate" to CT logs before issuing the final certificate. A precertificate is identical to the final certificate except for a special poison extension. This lets the CA get SCTs before the certificate is finalized.

Revoked certificates remain in the logs. CT logs are append-only. If a certificate is revoked, it still appears in the logs. The revocation status is not reflected in CT logs themselves. You need to check revocation status separately through CRL or OCSP.

Certificate renewal shows up as new entries. Every time you renew a certificate, the new certificate is logged as a separate entry. This is normal and expected.

Short-lived certificates still need CT. Even certificates with very short validity periods (like Let's Encrypt's 90-day certificates) must be logged to satisfy Chrome's CT requirements. Let's Encrypt submits all certificates to multiple CT logs automatically.

CT Log Operators

CT logs are operated by various organizations. As of 2025, active log operators include:

• Google operates several CT logs (Argon, Xenon, and others).
• Cloudflare operates the Nimbus logs.
• Let's Encrypt operates Oak logs.
• DigiCert operates Yeti and Nessie logs.
• Sectigo operates Mammoth and Sabre logs.

Logs have lifecycle stages: they start as "usable" (accepting new certificates), become "read-only" (no new submissions, but still verifiable), and are eventually "retired." Chrome maintains a list of trusted CT logs and their current status.

Limitations of Certificate Transparency

CT is a powerful detection mechanism, but it has boundaries.

CT does not prevent misissued certificates. It only makes them visible after the fact. If a CA issues a fraudulent certificate, it will appear in CT logs, but the certificate is still valid until it is revoked. The value of CT is that detection happens in hours or days rather than never.

Private CAs are not required to use CT. Organizations that operate their own internal CAs for internal services are not subject to CT requirements. This is by design, as internal certificates would expose information about internal infrastructure.

CT logs do not contain private keys. The certificate (which contains only the public key) is logged. Your private key is never involved in the CT system.

Log misbehavior is theoretically possible. A CT log operator could attempt to show different views of the log to different parties (a "split view" attack). The auditor component of CT is designed to detect this, but real-world auditing infrastructure is still maturing.

Understanding the certificate chain helps you interpret CT log entries, as each logged certificate references its issuing CA. If you suspect a certificate has been fraudulently issued, knowing how to validate certificates and what SSL inspection involves will help you investigate.

References

• RFC 6962 - Certificate Transparency
• Google - Certificate Transparency Policy
• crt.sh - Certificate Search
• Certificate Transparency - How It Works