The trust behind every padlock rests on Certificate Authorities issuing the right certificates to the right people. But for years there was no way to check whether they did — a CA could issue a certificate for your domain, by mistake or because it was fooled, and you'd never know. Certificate Transparency (CT) closes that blind spot by making every issued certificate public, in append-only logs anyone can read. This guide explains what CT is, how its logs and Signed Certificate Timestamps work, why browsers now refuse certificates that aren't logged, and how you can use it to watch your own domain.
In short
Certificate Transparency requires CAs to publish every certificate to public, append-only logs before it's used. Each logged certificate gets a Signed Certificate Timestamp (SCT) — a receipt browsers check; a publicly-trusted certificate without valid SCTs is rejected. CT doesn't encrypt anything — it makes mis-issuance impossible to hide, complementing CAA records (which restrict who may issue) with a public logbook of what was actually issued.
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 that's 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, and others run their own — so the record doesn't depend on any single party. The properties that make a log trustworthy are worth spelling out:
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. Tampering with one old entry would change the top hash and be immediately obvious.
Public and append-only forever
Anyone can read a log and anyone can monitor it. There's no privileged access — the transparency is the point. Domain owners, researchers, and browsers all read the same public record.
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.
Three ways an SCT reaches the browser
- Embedded in the certificate — the most common method, set up 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.
- OCSP stapling — SCTs are delivered alongside a stapled OCSP response.
Because the embedded method is overwhelmingly the norm, most site owners get CT for free — the SCTs are simply part of the certificate the CA issues.
How browsers enforce CT
CT only works if certificates that skip the logs get punished — and the punishment is the browsers. Major browsers require publicly-trusted certificates to present valid SCTs, and reject those that don't with a certificate error. To stop a single rogue log from waving bad certificates through, browsers generally want SCTs from more than one independently operated log, so no single log is a point of failure.
| Browser | CT requirement |
|---|---|
| Google Chrome | Requires CT for publicly-trusted certificates (enforced since 2018). Certificates without acceptable SCTs are rejected. |
| Apple Safari | Requires CT for certificates trusted by Apple platforms, with its own log policy. |
| Microsoft Edge | Built on Chromium, so it follows Chrome's CT policy. |
| Mozilla Firefox | Has historically applied CT more narrowly than Chrome; check current Mozilla policy for the latest scope. |
The practical upshot: a CA that wants its certificates to work in real browsers has no choice but to log them. That's what turns CT from a nice idea into a near-complete public record of issuance — the same property that makes certificate-issuance statistics drawn from CT logs so reliable.
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 for any certificate issued in their name, so an unexpected one raises a flag. Auditors check the logs' own integrity: they verify, using the 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 defense: 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.
CT is detection, not prevention
This is the distinction that trips people up. CT is 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 knowing 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 recognize — 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.
- 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.