Certificate Transparency Logs

In 2011, attackers compromised DigiNotar, a Dutch Certificate Authority. They issued over 500 fraudulent certificates—including ones for google.com, microsoft.com, and intelligence agencies. For weeks, these certificates existed in the wild, potentially enabling man-in-the-middle attacks on millions of users.

The only reason anyone discovered the compromise? A single user in Iran noticed a certificate warning in Chrome and posted about it online.

This is the problem Certificate Transparency solves. Before CT, a compromised or coerced CA could issue fake certificates for any domain, and unless someone happened to catch them being used, the certificates would remain invisible forever. CT makes the invisible visible.

The Core Idea

Certificate Transparency requires every publicly-trusted SSL certificate to be recorded in public logs before browsers will accept it. These logs are append-only—once a certificate is logged, it cannot be removed or modified. Anyone can read them.

This creates accountability through visibility. If a CA issues a certificate for your domain, it will appear in CT logs. If an attacker obtains a fraudulent certificate through CA compromise, it will appear in CT logs. If a government coerces a CA into issuing surveillance certificates, they will appear in CT logs.

The question CT answers: "Who watches the watchmen?" The answer: everyone can, now.

How It Works

When a Certificate Authority issues a certificate, they must submit it to at least two independent CT logs. The logs return a Signed Certificate Timestamp (SCT)—cryptographic proof that the certificate was logged.

This SCT gets embedded in the certificate itself. When your browser connects to a website, it checks for valid SCTs. No SCTs? The browser rejects the certificate.

The result: CAs cannot issue certificates in secret. Every certificate they create leaves a permanent, public trail.

The Append-Only Guarantee

CT logs use a data structure called a Merkle tree to prove they haven't been tampered with. Each new certificate gets incorporated into the tree, changing the root hash in a predictable way.

Monitors can mathematically verify that the log only grows—that entries are never removed or modified. If a log operator tried to delete a certificate to hide evidence of mis-issuance, the inconsistency would be cryptographically detectable.

This isn't trust. It's math.

What Browsers Require

Chrome requires SCTs from at least two independent log operators for certificates valid longer than 180 days. Safari has similar requirements. Firefox currently warns but doesn't block.

These requirements forced universal adoption. CAs that don't log certificates find their certificates rejected by browsers. The market made CT compliance mandatory without any law requiring it.

Monitoring Your Domains

The real power of CT is that you can watch it yourself. Services like crt.sh let you search for all certificates ever issued for your domain. Facebook and Google offer monitoring that alerts you when new certificates appear.

This matters because it turns a invisible attack into a detectable one. If someone compromises a CA and obtains a certificate for your domain, you can know within hours instead of never.

Set up monitoring. It's free, and it's one of the few proactive defenses available against CA compromise.

The Privacy Trade-Off

Every domain name in every certificate becomes public. This includes internal subdomains, staging environments, and domains for unreleased products. If you get a publicly-trusted certificate for secret-project.internal.yourcompany.com, that name is now in CT logs forever.

For truly private domains, use certificates from a private CA that isn't publicly trusted. Private CA certificates don't require CT logging because browsers don't trust them for public websites anyway.

Pre-Certificates

You'll often see two entries for what looks like the same certificate. This is because CAs submit a "pre-certificate" to logs first, get the SCTs, then issue the final certificate with those SCTs embedded.

Both appear in logs. It's not duplication—it's how the workflow ensures certificates include proof of logging from the moment they're issued.

What CT Doesn't Do

CT doesn't prevent phishing. Attackers can get legitimate certificates for domains like app1e.com just like anyone else. Those certificates get logged like any other.

CT also doesn't tell you if a certificate is currently valid. Revoked certificates remain in logs forever—the log records that a certificate was issued, not that it's still trustworthy. Check revocation status separately.

The Logs Themselves

CT logs are operated by Google, Cloudflare, DigiCert, Let's Encrypt, and others. Each is independent. The diversity prevents any single entity from controlling the system.

Logs must be publicly accessible and auditable. Misbehaving logs—ones that violate the append-only property or become unreliable—get distrusted by browsers, rendering them useless.

Why This Matters

Before CT, the certificate system ran on blind trust. We trusted CAs not to be compromised, not to be coerced by governments, not to make mistakes. When that trust was violated—DigiNotar, Comodo, WoSign—we only found out through luck or attacker error.

CT doesn't prevent CA compromise. It makes CA compromise visible. And visibility changes the game. A CA that knows every certificate it issues will be publicly logged behaves differently than one operating in the dark.

The Internet's security infrastructure is now auditable by anyone with an Internet connection. That's what CT accomplished.