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.
Certificate Transparency relies on three types of participants working together. Each plays a distinct role in ensuring that certificate issuance remains open and verifiable.
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.
Together, these three roles create a system of mutual accountability. CAs cannot secretly issue certificates because the logs are public. Logs cannot silently tamper with records because auditors verify their consistency. And domain owners can spot unauthorized issuance because monitors watch the logs continuously.
CT logs use a cryptographic data structure called a Merkle hash tree to guarantee tamper evidence. Understanding the basics of this structure helps explain why CT logs are so difficult to manipulate.
Each certificate entry in the log becomes a leaf node. The certificate data is hashed to produce a unique fingerprint. This means that every certificate in the log has a fixed, verifiable position.
Pairs of leaf hashes are combined and hashed again to produce parent nodes. This process repeats up the tree until a single root hash is produced. If any leaf changes, the root hash changes too, making tampering immediately detectable.
Anyone can ask a log server to prove that a previous version of the tree is a subset of the current version. This is how auditors verify that entries were never removed or altered between two points in time.
Given a specific certificate, the log server can produce a compact proof (a small set of hashes) that demonstrates the certificate is part of the tree. This allows efficient verification without downloading the entire log.
The elegance of Merkle trees is that they make it computationally infeasible to alter a log without detection. Even a single changed byte in any certificate would produce a different root hash, and any auditor comparing snapshots of the tree would immediately notice the discrepancy.
Certificate Transparency delivers value to multiple participants in the PKI ecosystem. Here is how each group benefits:
Domain owners can monitor CT logs to detect certificates issued for their domains that they did not authorize. This is critical for catching phishing sites, CA compromise, or internal mis-issuance before damage is done. Organizations that monitor for shadow certificates often rely on CT data as a primary source.
Browsers enforce CT requirements so that users are protected even if they never interact with CT directly. By requiring valid SCTs before trusting a TLS certificate, browsers ensure that every certificate has been publicly logged and is therefore subject to scrutiny.
While CT creates accountability for CAs, it also benefits them. A CA that logs all its certificates demonstrates good practice and builds trust with browser vendors. CT also helps CAs detect if their infrastructure has been compromised, since unauthorized issuance would appear in the public logs.
Browser vendors have been the primary driving force behind CT adoption. Each major browser has its own policy regarding how many SCTs a certificate must carry and which logs are considered trusted.
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.
Certificate Transparency is a significant improvement to the PKI ecosystem, but it is not a complete solution on its own. Understanding its limitations is important for setting realistic expectations.
CT makes mis-issuance visible, but it does not prevent it from happening. A compromised CA can still issue a fraudulent certificate. The value of CT lies in ensuring that the fraud is discovered quickly, not in blocking it at the source. Remediation still depends on revocation mechanisms and browser enforcement.
CT applies only to publicly trusted certificates. Internal certificates issued by private CAs are not logged, which means CT provides no visibility into an organization's internal PKI. For organizations with large private certificate estates, separate discovery and monitoring tools are essential.
CT depends on log operators running stable, available infrastructure. If a log server goes down or misbehaves, certificates that rely on SCTs from that log may face trust issues. Browser vendors maintain lists of approved logs and will remove operators that fail to meet uptime or consistency standards.
Because CT logs are public, they reveal the existence of every domain and subdomain for which a public certificate was issued. This can expose internal infrastructure naming conventions, staging environments, or acquisition targets. Organizations that value domain privacy should consider wildcard certificates or be deliberate about what subdomains they certify publicly.
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.
