Certificate Transparency is an open framework of logs, monitors, and auditors that makes it nearly impossible for a certificate authority to issue a certificate without the domain owner knowing about it. It is one of the most important accountability mechanisms in modern PKI.
In 2011, a Dutch Certificate Authority called DigiNotar was compromised. Attackers issued fraudulent certificates for major domains, including *.google.com, and used them to intercept the communications of hundreds of thousands of people. The breach went undetected for weeks because there was no public, auditable record of which certificates had been issued, or by whom.
The DigiNotar incident (along with similar events involving Comodo and other CAs) exposed a fundamental weakness in the PKI ecosystem: the trust model assumed that every CA would behave correctly at all times, but offered no mechanism to verify that assumption. Domain owners had no practical way to know whether a rogue or compromised CA had issued a certificate for their domain.
Certificate Transparency (CT) was created by Google engineers Ben Laurie and Adam Langley to solve this problem. Defined in RFC 6962 (and later updated by RFC 9162), CT introduces a system of publicly auditable, append-only logs that record every certificate a participating CA issues. The idea is simple but powerful: if every certificate must be logged before it is trusted, then fraudulent or mistaken issuance becomes visible to anyone who cares to look.
When a CA issues a certificate, it submits that certificate (or a precertificate) to one or more CT log servers. These logs are append-only, meaning entries can be added but never modified or deleted. The log server returns a Signed Certificate Timestamp (SCT), which is a cryptographic promise that the certificate will appear in the log within a defined time window (the Maximum Merge Delay, typically 24 hours).
Monitors are services that watch CT logs for new entries. Domain owners (or security teams acting on their behalf) use monitors to detect certificates issued for their domains. If a certificate appears that the domain owner did not request, it is a strong signal of either CA compromise or mis-issuance. Services like Google's Certificate Transparency search, crt.sh, and commercial CLM platforms all act as monitors.
Auditors verify the integrity of the logs themselves. They check that logs are behaving correctly: that entries are not being removed, that the Merkle tree structure is consistent, and that SCTs correspond to actual log entries. Browsers can act as auditors by verifying that presented SCTs match log records.
Chrome was the first browser to require CT and has the strictest policy. Since April 2018, all newly issued publicly trusted certificates must be accompanied by SCTs from at least two independent CT logs. Certificates without valid SCTs are treated as untrusted and trigger a full-page warning.
Apple requires CT compliance for all TLS certificates issued after October 15, 2018. Safari requires SCTs from at least two logs, and one of those logs must have been in a "qualified" state at the time the certificate was issued. Apple maintains its own list of trusted CT logs.
Firefox has historically not enforced CT requirements at the browser level, relying instead on CAs complying voluntarily. However, Mozilla has signaled increasing interest in CT enforcement through its root program policies, and practical enforcement is expected to follow Chrome and Apple's lead.
SCTs can be delivered to browsers in three ways: embedded directly in the certificate (the most common approach), via a TLS extension during the handshake, or through OCSP stapling. Each method has trade-offs in terms of deployment complexity and server configuration.
CT log monitoring — Evertrust CLM ingests data from Certificate Transparency logs to detect certificates issued for your domains, whether you requested them or not. This gives you immediate visibility into unauthorized or unexpected issuance.
Complete inventory — CT data is combined with network scanning and connector-based discovery to build a unified inventory that covers both public and private certificates. No blind spots, no shadow certificates hiding outside your field of view.
Alerting on anomalies — When a certificate appears in CT logs for one of your domains that does not match your known inventory, Evertrust raises an alert so your security team can investigate and respond before any damage occurs.
Policy enforcement — Evertrust helps you define and enforce policies that ensure all public certificates are CT-compliant, reducing the risk of browser trust failures across your infrastructure.
