A plain-language guide to the public logs that record every TLS certificate and help browsers catch rogue ones.
- Certificate Transparency is a public, append-only record of every TLS certificate that authorities issue.
- It exists to catch mis-issued, rogue, or mistaken certificates before they cause harm.
- Logs use Merkle trees, so entries cannot be changed or secretly removed.
- Signed Certificate Timestamps (SCTs) prove a certificate was logged; browsers require them to trust it.
- You can search the logs with crt.sh or our SSL Certificate Checker.
Every time you load a secure website, your browser checks a certificate behind the scenes. That certificate proves the site is who it claims to be. But what stops a certificate authority from issuing a certificate for a domain it should not?
Certificate Transparency answers that question. It is the public audit layer that keeps the certificate system honest. This guide explains what Certificate Transparency is, why it exists, and how you can use it today.
What is certificate transparency?
Certificate Transparency is a public framework that records every TLS certificate a certificate authority issues. It uses open, append-only logs that anyone can inspect. The goal is simple: make certificate issuance visible so rogue or mistaken certificates cannot hide.
Certificate Transparency, often shortened to CT, is an open security standard for the web’s certificate system. It was first defined in RFC 6962 and is now backed by major browser vendors.
Under CT, certificate authorities publish a record of each certificate they issue. These records go into public logs that anyone can read or audit.
The system does not replace SSL/TLS. It sits alongside it as a transparency and accountability layer. If you want the full picture of the encryption beneath it, see our guide on how SSL certificates work.
Why certificate transparency exists
Certificate Transparency exists because the old trust model had a blind spot. A single compromised or careless certificate authority could issue a certificate for any domain. Public logs expose that issuance, so domain owners and researchers can spot fraudulent certificates fast.
Before CT, the certificate system relied on blind trust. Browsers trusted hundreds of certificate authorities without any public record of what each one issued.
That created a dangerous gap. A hacked or rogue authority could mint a valid certificate for a bank, an email provider, or any site. Victims would see a normal padlock and notice nothing wrong.
Real incidents proved the risk. The 2011 DigiNotar breach produced fraudulent certificates for Google and other domains. The attack helped spark the push for public logging.
CT closes the gap by making issuance visible. When every certificate is logged, a fake one stands out and can be revoked quickly.
How certificate transparency logs work
Certificate Transparency logs are append-only databases built on Merkle hash trees. Entries can be added but never edited or deleted. Each log periodically signs its current state as a Signed Tree Head. That cryptographic structure lets anyone detect tampering or split-view cheating.
CT logs are the heart of the system. Each log is a network service that accepts certificates and stores them permanently.
Append-only by design
A log only grows. New certificates are added as leaves, and nothing already recorded can change.
This works through a Merkle tree, a structure of hashes that chains every entry together. Altering one record would break every hash above it.
Signed tree heads
Periodically, the log signs a snapshot of its contents. This snapshot is called a Signed Tree Head, or STH.
Independent monitors collect these snapshots and compare them. If a log ever shows two conflicting views, the mismatch is caught.
Logs, monitors, and auditors
Three roles keep the system honest. Logs store certificates, monitors watch logs for suspicious entries, and auditors verify that logs behave correctly.
Browser vendors and certificate authorities run many of these logs. Sharding splits older entries by time period to keep each log manageable.
What are Signed Certificate Timestamps (SCTs)?
A Signed Certificate Timestamp is a log’s signed promise to include a certificate soon. The CA submits a certificate and receives an SCT in return. The log must then add that certificate within a window called the Maximum Merge Delay, usually 24 hours.
An SCT is the visible proof that a certificate was logged. Think of it as a timestamped receipt from a CT log.
Here is the basic flow. The certificate authority submits a pre-certificate to one or more logs. Each log returns an SCT, promising to add the entry within the Maximum Merge Delay.
The MMD is usually 24 hours under current browser policies. Within that window, the log must merge the certificate into its Merkle tree.
SCTs reach your browser in three ways. They can be embedded in the certificate, delivered in the TLS handshake, or stapled with OCSP. Embedded SCTs are by far the most common.
Browser rules keep tightening here. Chrome is phasing out OCSP-delivered SCTs in version 148, released May 2026.
How browsers enforce certificate transparency
Modern browsers refuse to trust a public certificate that lacks valid SCTs. Chrome, Safari, and Firefox all require Certificate Transparency proof during TLS validation. The exact SCT count depends on certificate lifetime and which log operators signed them.
Browsers do the enforcement work. During a TLS handshake, the browser checks that a public certificate carries enough valid SCTs.
If the proof is missing, the connection fails. Chrome shows an error and blocks the page rather than loading it.
The required SCT count depends on the certificate’s lifetime. Browsers also require SCTs from logs run by different operators, for resilience.
Chrome dropped its old “one Google log” rule in 2022. Today it asks for SCTs from at least two distinct log operators instead.
| Browser | Certificate 180 days or less | Certificate over 180 days | Notes |
|---|---|---|---|
| Chrome | 2 SCTs from distinct logs | 3 SCTs from distinct logs | Needs 2 distinct log operators; OCSP-delivered SCTs removed in Chrome 148. |
| Safari (Apple) | 2 SCTs (max 1 per operator) | 3 SCTs (max 2 per operator) | At least one SCT from an RFC 6962 compliant log. |
| Firefox | 2 SCTs from distinct logs | 2 SCTs from distinct logs | Enforced on desktop since v135 (2025) and Android since v145 (2025). |
These numbers shift over time. Always confirm the current rules against each vendor’s official policy page.
How to search certificate transparency logs
You can search Certificate Transparency logs to see every certificate issued for a domain. The crt.sh service, run by Sectigo, indexes public logs for free. Our SSL Certificate Checker queries crt.sh for you, surfacing issuance history without command-line work.
The same logs that protect browsers are open to you. Searching them reveals every certificate ever issued for a domain.
This is useful for several reasons. You can spot certificates you did not authorize, audit a vendor, or track your own renewals.
The best-known search tool is crt.sh, operated by Sectigo. You type a domain and it lists matching certificates from public CT logs. Cloudflare also runs a monitor called Merkle Town.
You do not need the command line to do this. Our SSL Certificate Checker queries CT data for any domain and shows the results in plain language.
Check any domain’s certificate history
See the live SSL certificate and its Certificate Transparency log entries in seconds.
Open the SSL Certificate CheckerFrequently asked questions
These common questions cover Certificate Transparency basics, including SCT counts, log operators, and privacy effects. The short answers below summarize current browser behavior in 2026. Each one stays vendor-neutral and points to primary sources for the precise, changing technical details.
Is certificate transparency the same as SSL or TLS?
No. SSL and TLS encrypt the connection between your browser and a server. Certificate Transparency is a separate layer that publicly logs the certificates those connections rely on. The two work together but solve different problems.
How many SCTs does a certificate need?
It depends on the certificate lifetime and the browser. Chrome and Apple require 2 SCTs for certificates valid 180 days or less, and 3 SCTs for longer ones. The SCTs must come from logs run by different operators.
Does certificate transparency make my internal domains public?
It can. Any certificate issued by a public certificate authority gets logged, including ones for internal hostnames. The domain names become searchable, so avoid putting secrets in certificate names. Use a private internal CA if you need names to stay hidden.
What is the Maximum Merge Delay?
The Maximum Merge Delay is the deadline for a log to add a certificate. After issuing an SCT, the log promises to include that certificate within the window. Under current Chrome policy the limit is 24 hours.
Who can search certificate transparency logs?
Anyone can. The logs are public by design, so no account or special access is needed. Tools like crt.sh let you search by domain for free. Our SSL Certificate Checker does the same lookup in a friendlier format.
What happens if a certificate has no SCTs?
Modern browsers reject it. A public certificate without valid Certificate Transparency proof fails validation in Chrome, Safari, and Firefox. The user sees a security warning instead of the page. This only applies to publicly trusted certificates, not private internal ones.
Related tools and resources
Certificate Transparency connects to several tools and guides on NetworkCheckr. The SSL Certificate Checker reads CT log data directly for any domain. The guides below explain how SSL works and how to read related certificate and domain records.
References
The sources below are primary references for Certificate Transparency rules and mechanics. RFC 6962 defines the original standard, while browser vendors publish their own SCT policies. Always check these pages directly, since SCT counts and log requirements change over time.
- RFC 6962 — Certificate Transparency (IETF)
- How CT Works (certificate.transparency.dev)
- Apple’s Certificate Transparency policy (Apple Support)
- Chrome Certificate Transparency Policy (Google)