Certificate transparency (CT) is a system of public, append-only logs in which certificate authorities record every TLS certificate they issue, so that domain owners, browsers and researchers can detect misissued or fraudulent certificates. In Internet trust, it closes a gap in the classic PKI model: before CT, a certificate could be issued for any domain by any trusted authority, and nobody outside that authority would necessarily know.
CT was developed after high-profile authority compromises around 2011 and is specified in RFC 6962, with a revised version 2.0 in RFC 9162. Major browsers now require proof of logging before they accept a publicly trusted certificate, which makes CT a mandatory part of the web PKI rather than an optional add-on.
How certificate transparency logs work
A CT log is a server that stores submitted certificates in a Merkle hash tree. Each new entry changes the root hash, and the log periodically publishes a Signed Tree Head (STH) that commits to its entire contents. Because every root depends on every earlier entry, the log cannot remove or alter a record without producing a detectably inconsistent tree.
Before issuing, an authority usually submits a precertificate, a version of the certificate carrying a poison extension that prevents its use. The log returns a Signed Certificate Timestamp (SCT), a promise to incorporate the entry within the Maximum Merge Delay, typically 24 hours. The authority then embeds the SCTs into the final certificate.
| Element | What it is | Who checks it |
|---|---|---|
| Precertificate | Unusable copy submitted before issuance | Log operator |
| Signed Certificate Timestamp | Log’s signed promise to include an entry | Browser during the TLS handshake |
| Signed Tree Head | Signed root hash and tree size | Monitors and auditors |
| Inclusion proof | Hash path from entry to root | Auditors and clients |
| Consistency proof | Shows a newer tree extends an older one | Auditors |
Delivering proof of logging to browsers
A browser must see valid SCTs before it trusts a certificate. There are three delivery methods, and almost all certificates today use the first one because it needs no server configuration.
| Method | How SCTs reach the client | Practical note |
|---|---|---|
| X.509 extension | Embedded in the certificate itself | Default for nearly all public authorities |
| TLS extension | Sent by the server in the handshake | Requires server support and SCT files |
| OCSP stapling | Included in the stapled OCSP response | Rare, depends on the authority |
Browser policies define how many SCTs from how many independent operators are required, usually two or three SCTs depending on certificate lifetime, with logs from at least two different operators. Chrome and Safari enforce such policies, and each maintains a list of qualified logs.
Roles in the CT ecosystem
CT works only because several independent parties watch each other. No single participant needs to be trusted completely.
- Log operators run the logs and must stay available, append-only and consistent; a log that misbehaves is removed from browser lists.
- Certificate authorities submit certificates and embed SCTs before delivering them to customers.
- Monitors download every log entry and alert domain owners to certificates issued for their names.
- Auditors verify inclusion and consistency proofs, catching logs that show different views to different clients.
- Domain owners subscribe to monitoring and investigate any certificate they did not request.
Logs are commonly sharded by expiry year, so that each shard accepts only certificates expiring in a given period and can be frozen afterwards. This keeps individual trees from growing without limit; the largest logs together hold billions of entries.
Certificate transparency compared with related controls
CT is a detection mechanism, not a prevention mechanism. It works best when combined with controls that act before issuance or at connection time.
| Mechanism | Type of control | Main limitation |
|---|---|---|
| Certificate transparency | Public detection after issuance | Damage possible before anyone reacts |
| CAA record | Restricts which authorities may issue | Relies on authorities obeying it |
| Certificate pinning | Client accepts only expected keys | Risky to operate, mostly abandoned on the web |
| OCSP and CRL | Revocation after a problem is found | Inconsistent client checking |
| HSTS | Forces HTTPS for a domain | Does not judge which certificate is valid |
In a typical incident, CT reveals the rogue certificate, revocation through a certificate revocation list or OCSP withdraws it, and browser vendors may distrust the responsible authority if the root cause is systemic.
Privacy effects and common misunderstandings
Because logs are public, every hostname in a certificate becomes visible within minutes of issuance. Attackers routinely watch CT feeds to discover new staging servers, internal tools and unreleased product names. Organizations that want to hide internal names use wildcard certificates or a private PKI that is not logged.
A frequent misconception is that a logged certificate is a legitimate one. Logging proves only that the certificate is public, not that the requester controlled the domain. Another is that CT protects automatically: without someone actively monitoring the logs for a domain, a misissued certificate can stay unnoticed for its whole lifetime. Free and commercial monitoring services, as well as searchable CT databases, make this monitoring practical for organizations of any size.
CT also has operational limits. Logs occasionally become unavailable or are retired, and authorities must then obtain SCTs from other qualified logs. Short-lived certificates, which are increasingly common, multiply the number of entries, so log operators keep reducing storage costs through new designs such as static tile-based logs that serve the tree as cacheable files rather than through a dynamic interface. Domain owners are not affected by these changes, but they explain why the set of active logs changes from year to year.
A plain-language summary
Certificate authorities are like notaries that vouch for a website’s identity. Certificate transparency makes every one of those notaries write each stamp into a public ledger that nobody can erase.
Website owners can read the ledger at any time. If they find a certificate for their name that they never asked for, they know something is wrong and can have it canceled quickly.
An example from practice
A payment company subscribes to a CT monitoring service that alerts its security team whenever a certificate containing its domain names appears in any log. One evening an alert reports a certificate for login.paycompany-support.com and, more worryingly, one for api.paycompany.com issued by an authority the company does not use.
The first is a lookalike phishing domain, which the team reports for takedown. The second turns out to be ordered by a marketing agency that used an old DNS delegation. The team has the certificate revoked within hours, removes the stale delegation and adds a CAA record limiting issuance to its two approved authorities, so the gap that CT exposed is also closed at the issuance stage.