The short answer
Certificate Transparency (CT) is a public, append-only record of every SSL/TLS certificate issued by a publicly trusted Certificate Authority. Before a certificate works in a browser, the CA submits it to independent logs, which return signed receipts called SCTs that are then embedded in the certificate itself. As of August 2026, Chrome requires SCTs from two distinct logs for certificates valid 180 days or less and three for longer ones, and Firefox has enforced CT on desktop since version 135 — so an unlogged public certificate simply fails to load. CT doesn't encrypt anything and doesn't prevent mis-issuance; it makes issuance impossible to do in secret.
What Certificate Transparency is
Certificate Transparency is an open framework — first specified by Google engineers in RFC 6962 in 2013, and updated as version 2.0 in RFC 9162 — that creates a public, tamper-evident record of the SSL/TLS certificates issued by publicly trusted Certificate Authorities. The idea is almost disarmingly simple: every certificate meant to be trusted by browsers should be written into a log that anyone can inspect, and that no one can quietly rewrite.
It helps to be clear about what CT is not. It doesn't encrypt traffic, it isn't a new kind of certificate, and it doesn't change the TLS handshake that secures your connection. CT operates one layer up, at the level of governance: it's an accountability system for the act of issuing certificates. A certificate still does exactly what it always did; CT just guarantees that its creation happened in the open.
The problem CT was built to solve
The whole public-key infrastructure depends on browsers trusting a set of Certificate Authorities to vouch for who owns which domain. That trust is powerful — and, before CT, almost entirely unchecked. Any trusted CA could issue a certificate for example.com, and there was no central, public place to notice it had done so. The legitimate owner of the domain had no reliable way to discover a certificate they hadn't requested.
That gap wasn't theoretical. High-profile cases of CAs issuing certificates they never should have — through compromise, error, or being deceived — showed that a single misbehaving or breached CA could be used to impersonate any site on the web, silently. The victim couldn't see it; the attacker's certificate looked perfectly valid to browsers. The missing ingredient wasn't stronger cryptography — it was visibility.
The core insight: you can't prevent every mistake a CA might make, but if every certificate must be published where the world can see it, mistakes and abuse can't stay hidden — and anything that can't stay hidden becomes far less useful to an attacker and far easier to hold a CA accountable for. CT trades secrecy for scrutiny.
How CT logs work
A CT log is a network service that does one job: it accepts certificates and records them in an order that can never be secretly altered. Several independent organizations operate these logs — Google, Cloudflare, DigiCert, Let's Encrypt and others run their own — so the record doesn't depend on any single party. Three properties are what make a log worth trusting.
Append-only
Once a certificate is added, it can never be removed or edited. There's no "delete" — which is exactly what you want from an audit trail. A CA can't log a certificate and later make it disappear.
Cryptographically verifiable
Logs are built on a Merkle tree — a hash structure where the single value at the top depends on every entry beneath it. That lets anyone prove a specific certificate is in the log, and prove the log hasn't been retroactively rewritten, without downloading the whole thing.
Readable by anyone
There's no privileged access — the transparency is the point. Domain owners, researchers, and browsers all read the same public record, and none of them needs the log operator's permission to do it.
When a log accepts a certificate, it commits to publishing that entry within a fixed window called the Maximum Merge Delay, commonly 24 hours. That promise — backed by the log's signature — is what makes the next piece, the SCT, meaningful.
SCTs and precertificates
A Signed Certificate Timestamp (SCT) is the receipt a log hands back when it accepts a certificate. It's a small, signed statement that says, in effect: I, this log, received this certificate at this time and will publish it within the Maximum Merge Delay. Because it's signed by the log, it can't be forged. Browsers treat SCTs as the proof that a certificate is properly logged — no acceptable SCTs, no trust.
There's a chicken-and-egg wrinkle, though. Browsers prefer the SCT to live inside the certificate, but you can't embed a log's receipt into a certificate before that certificate exists. CT solves this with a precertificate: the CA creates a special preliminary version of the certificate, submits it to the logs, collects the SCTs, and then bakes those SCTs into the final certificate it issues. By the time you receive your certificate, the receipts are already inside it.
How an SCT reaches the browser
- Embedded in the certificate — the overwhelmingly common method, arranged via the precertificate before issuance. The SCTs travel inside the certificate, so no server configuration is needed.
- TLS extension — the server presents SCTs during the handshake. Most TLS servers don't support this, which is precisely why CAs embed instead.
- OCSP stapling — historically a third route, delivered alongside a stapled OCSP response. Chrome accepts SCTs this way only in versions before 148, so treat it as a legacy path rather than something to build on.
How browsers enforce CT in 2026
CT only works if certificates that skip the logs get punished, and the browsers are the punishment. Chrome has required CT for publicly trusted certificates issued after April 30, 2018, enforced from Chrome 68 onward. Firefox joined properly in 2025: CT is enforced by default on desktop from version 135 and on Android from version 145, for certificates issued by CAs in Mozilla's Root CA Program. If you've read that Firefox ignores CT, that advice has expired.
| Browser | CT requirement as of August 2026 |
|---|---|
| Google Chrome | Enforced for publicly trusted certificates issued after April 30, 2018. Embedded SCTs must come from 2 distinct logs (lifetime ≤ 180 days) or 3 (longer), with at least 2 from different log operators. |
| Microsoft Edge | Built on Chromium, so it follows Chrome's CT policy and log list. |
| Mozilla Firefox | Enforced by default on desktop from Firefox 135 and Android from 145. Mozilla's policy is currently equivalent to Chrome's and it accepts the logs Chrome accepts. |
| Apple Safari | Enforced across Apple platforms with Apple's own policy: at least two SCTs, with the required count scaling by validity period, and at least one from an RFC 6962-compliant log. |
Two details in Chrome's policy are worth internalising because they explain most CT surprises. First, the required SCTs must come from different log operators, not merely different logs — that way one operator's outage or removal can't invalidate certificates wholesale. Second, Chrome stops enforcing CT entirely if its log list goes stale for more than 70 days, which is the safety valve that lets new logs join the ecosystem without breaking old browsers.
In practice none of this is your job. A CA that wants its certificates to work in real browsers has no choice but to log them, so every certificate My-SSL issues through Certum arrives with its SCTs already embedded — the same is true of any publicly trusted SSL certificate you buy. That universality is also what makes certificate-issuance statistics drawn from CT logs so reliable: near enough everything is in there.
Shorter certificates, fewer SCTs
Here's a connection most CT explainers miss. The number of SCTs Chrome demands depends on how long the certificate is valid: two distinct logs for 180 days or less, three for anything longer. Certificate lifetimes are meanwhile on a published downward schedule under CA/Browser Forum ballot SC-081v3 — 398 days until March 2026, 200 days from March 15, 2026, 100 days from March 15, 2027, and 47 days from March 15, 2029.
Line those two rules up and something concrete falls out. Today's 200-day maximum is still above the 180-day threshold, so current public certificates carry three embedded SCTs. When the maximum drops to 100 days in March 2027, every compliant certificate lands below the line and needs only two. Certificates get slightly smaller, handshakes carry a little less data, and CAs submit fewer entries per certificate — a small efficiency dividend hiding inside a change everyone is bracing for on renewal-frequency grounds.
The move to static, tiled logs
The CT ecosystem is midway through its first real architectural change, and it happened quietly enough that most guides haven't caught up. The original RFC 6962 log design is being replaced by the Static CT API, which serves the Merkle tree as plain static files — "tiles" of 256 entries — instead of answering dynamic queries from a database. A log becomes a directory of cacheable files rather than a fleet of servers, which cuts the cost of running one dramatically.
The migration is real and dated. Let's Encrypt made its RFC 6962 logs read-only on November 30, 2025 and shut them down entirely on February 28, 2026, writing only to Static CT logs from then on. Other operators are moving along the same path.
What changes for you: nothing
Certificates, SCTs, and browser checks all work the same way. The change is in how logs are built and paid for, and the reason it matters to you is indirect but real: cheaper logs mean more independent operators, and more operators is what keeps the "different log operators" requirement meaningful as certificate volumes climb.
Monitors, auditors, and crt.sh
A public record only helps if someone reads it. CT defines two roles around the logs that do exactly that. Monitors watch the logs for certificates of interest — typically a domain owner, or a service watching on their behalf, looking for any certificate issued in their name. Auditors check the logs' own integrity, verifying through Merkle proofs that a log is consistent over time and hasn't quietly rewritten history. Browsers act as lightweight auditors every time they check an SCT.
Searching the logs yourself
The best-known public search interface is crt.sh. Enter a domain — including a wildcard like %.example.com — and it lists every logged certificate that mentions it, with the issuing CA, validity dates, and the hostnames each one covers. It's a fast way to answer a genuinely useful question: has anyone been issued a certificate for my domain that I didn't request?
For continuous coverage rather than spot checks, many certificate-monitoring services and some CAs offer CT monitoring that emails you whenever a new certificate naming your domain appears in a log. Pairing that with CAA records gives you both halves of the defence: CAA restricts who may issue, CT alerts you if something was issued anyway.
What CT does and doesn't do
It's easy to over- or under-sell Certificate Transparency, so it's worth being precise about its scope.
What CT does
- Makes every publicly trusted certificate discoverable in public logs.
- Lets domain owners detect certificates they never requested.
- Holds CAs accountable, since mis-issuance can't stay hidden.
- Provides the most objective data on real-world certificate issuance.
What CT doesn't do
- It doesn't encrypt traffic or strengthen the TLS connection itself.
- It doesn't prevent a CA from issuing a bad certificate.
- It doesn't act on its own — someone has to monitor the logs.
- It doesn't cover privately trusted or internal CAs.
The side effect nobody warns you about
Every hostname in a publicly trusted certificate becomes public the moment it's logged. Request a certificate for staging.example.com and that name is searchable forever — the logs are append-only, so you can't take it back. Attackers routinely mine CT for exactly this reason. If a hostname has to stay quiet, cover it with a wildcard certificate that never names it, or use an internal CA whose certificates aren't subject to CT.
CT is detection, not prevention. It's a smoke detector, not a lock — it tells you something happened, fast and reliably, but it doesn't stop it. That's by design, and it's why CT pairs with preventive controls like CAA. The deterrent value is real, though: a CA that knows every issuance is public, permanent, and attributable behaves very differently from one operating in the dark.
What this means for you
For most site owners, CT is something you benefit from without configuring. Still, a few concrete moves turn it from background plumbing into a real security tool.
- You don't set up CT yourself. Your CA logs your certificate and embeds the SCTs before handing it over. There's no CT directive to enable on Nginx, Apache, or IIS — install your certificate as normal and the SCTs are already inside it.
- Search the logs for your domain. Run your domain through crt.sh and review the results for any certificate you don't recognise — an unfamiliar CA, hostnames you didn't request, or dates that don't line up with your renewals.
- Set up CT monitoring. If your domain matters, use a service that emails you when a new certificate for it appears in a log. That's your early warning for both mistakes and abuse.
- Think before you name a host. Every SAN you request goes public. Decide deliberately which hostnames you're willing to publish, and reach for a wildcard when you aren't.
- Combine CT with CAA. Publish CAA records to restrict which CAs may issue for your domain, and lean on CT to confirm nothing slipped through. Restriction plus verification is far stronger than either alone.
Certificate Transparency is one of those quiet improvements that made the whole Web PKI more honest without most people noticing. If you want the layers underneath it, start with how SSL works and what PKI is, then see how revocation handles certificates that have to be pulled in our guide to certificate revocation.
Every certificate we issue is already in the logs
CT compliance isn't a feature you shop for — it's the baseline any publicly trusted CA has to meet. My-SSL issues through Certum, a publicly trusted CA, so the SCTs are embedded before the certificate reaches you. If you're deciding which type of certificate you actually need, the SSL certificate range is the place to compare DV, OV, and EV side by side.
Related reading
- CAA records explained — the preventive half of the pair, restricting which CAs may issue for your domain.
- Certificate revocation: CRL vs OCSP — what happens after a bad certificate is found in the logs.
- The 2026 certificate lifetime changes — the schedule that decides how many SCTs your certificates carry.