TLS certificates and Certificate Transparency, explained.
What a certificate actually proves, the chain of trust behind the padlock, and how Certificate Transparency logs make a mis-issued certificate impossible to hide.
The padlock icon in a browser's address bar is one of the most misread symbols on the internet. Most people read it as "this site is safe." What it actually means is much narrower: the connection to this domain is encrypted, and a certificate authority confirmed that whoever requested this certificate controlled the domain at the moment they asked for it. That's it. A phishing domain registered ninety seconds ago can have a perfectly valid, padlock-showing certificate — free, automatic, and issued in under a minute by Let's Encrypt. Understanding what a TLS certificate really attests, and how Certificate Transparency keeps the whole system honest, is the difference between trusting a symbol and trusting a system you actually understand.
What a certificate actually is
A TLS certificate is a small, cryptographically signed file that binds a public key to a domain name. When you connect to a site over HTTPS, the server presents its certificate; your browser checks that the signature traces back to a root certificate authority (CA) it already trusts, and that the domain name in the certificate matches the one you're visiting. If both checks pass, your browser can use the certificate's public key to set up an encrypted channel — the mechanics of which we cover in how networks actually work, where a full TLS handshake is traced step by step.
What the certificate is not is a background check on the website's owner, intentions, or trustworthiness. It proves domain control at issuance time, full stop. That distinction matters more than almost any other fact in this article.
The chain of trust
No browser trusts a website's certificate directly. Instead, trust flows down a chain, each link signing the one below it:
| Link | Role | Example |
|---|---|---|
| Root CA | The ultimate trust anchor. Its certificate ships pre-installed in your OS and browser trust store. Kept offline and used rarely, precisely because compromising it would be catastrophic. | ISRG Root X1 (Let's Encrypt), DigiCert Global Root |
| Intermediate CA | Signed by the root, used for day-to-day certificate issuance. If an intermediate is ever compromised, it can be revoked without touching the root. | R10/R11 (Let's Encrypt's issuing intermediates) |
| Leaf / end-entity certificate | The certificate a specific website actually presents to your browser. Signed by an intermediate, valid for one domain (or a short list of domains/subdomains). | The certificate for breachfolio.com itself |
Your browser verifies this chain link by link, all the way up to a root it already trusts. Break any link — an expired intermediate, a signature that doesn't verify, a domain mismatch — and you get the "connection is not private" warning instead of a padlock.
DV, OV, and EV: three levels of vetting, one identical padlock
Not every certificate involves the same amount of checking, even though the resulting padlock looks the same to almost everyone:
| Type | What's verified | How fast |
|---|---|---|
| DV — Domain Validated | Only that the requester controls the domain (via a DNS record or a file on the web server). No identity check at all. | Seconds to minutes, often automated and free (Let's Encrypt) |
| OV — Organization Validated | Domain control, plus the legal existence of the requesting organization, checked against business registries. | Hours to a few days, manual review, paid |
| EV — Extended Validation | The deepest check: legal identity, physical address, operational existence, phone verification. | Days, the most manual review, most expensive |
For years, EV certificates earned a visible reward: a green address bar showing the company's legal name. Starting in 2019, Chrome and most other major browsers quietly removed that special treatment, after usability research found almost nobody noticed or understood it. Today all three certificate types render as the exact same neutral padlock — which means the padlock alone has never told you less about who you're actually talking to than it does right now. This is also exactly why domain and DNS history matter more than the certificate itself when judging a site — see investigating a suspicious domain for the fuller workflow.
Why Certificate Transparency exists
The chain-of-trust model has one uncomfortable weakness: it depends entirely on certificate authorities behaving correctly, and for most of TLS's history there was no reliable way to check that they did. If a CA — through compromise, coercion, or plain error — issued a certificate for a domain to someone who didn't actually own it, the real domain owner had no way to find out. The clearest case study is DigiNotar, a Dutch CA breached in 2011. The attacker issued a rogue, fully valid certificate for *.google.com, which was later observed being used to intercept HTTPS traffic to Gmail in Iran. DigiNotar had no idea the certificate existed until researchers found it being actively used against real users.
Certificate Transparency (CT), proposed shortly after and now mandatory for any certificate a mainstream browser will trust, closes that blind spot. Every publicly trusted certificate must now be logged in one or more independent, public, append-only logs before a browser will accept it — which means every certificate ever issued for your domain is now a matter of searchable public record, whether you requested it or not.
How a CT log actually works
A CT log is built as a Merkle tree: every new certificate submitted to the log becomes a leaf, and each leaf is hashed together with its neighbors, layer by layer, up to a single root hash that represents every entry the log has ever contained. Change or delete a single past entry and the root hash changes too — a mismatch anyone can detect by comparing hashes. This is what "append-only" and "tamper-evident" mean in practice: it's not a promise the log operator makes, it's a property the math enforces.
When a CA submits a certificate to a log, the log returns a Signed Certificate Timestamp (SCT) — a cryptographic receipt proving the certificate was logged at a specific time. Browsers check for a valid SCT (or several, from independent logs) before trusting a certificate at all. No SCT, no trust, regardless of how legitimate the certificate otherwise looks. Multiple logs run by different, unaffiliated organizations (Google, Cloudflare, DigiCert, Sectigo, and others) cross-monitor each other specifically so that no single operator could quietly falsify history without the others noticing.
Reading CT logs yourself, with crt.sh
You don't need any special access to query this data — it's public by design. crt.sh is the easiest interface, searchable from a browser or the command line:
# Every certificate ever logged for a domain, including subdomains
$ curl -s "https://crt.sh/?q=%25.example.com&output=json" \
| jq -r '.[] | "\(.not_before) \(.name_value)"' \
| sort -u
2024-02-11T00:00:00 api.example.com
2023-08-03T00:00:00 mail.example.com
2026-01-14T00:00:00 vpn.example.comThat same query is exactly what powers the passive subdomain-enumeration technique described in domains vs subdomains — CT logs leak infrastructure nobody meant to publish, because every certificate names every hostname it covers. For a single domain, a browser search at crt.sh/?q=example.com works just as well and needs no tooling at all.
Monitoring your own domain
The practical payoff of CT isn't just historical research — it's an early-warning system. Because every new certificate for your domain gets logged publicly within minutes of issuance, you can monitor for certificates you never requested, which is one of the clearest possible signals of a compromised DNS zone, a hijacked subdomain, or a CA that was tricked into issuing something it shouldn't have.
- Manual spot-check: search
crt.sh/?q=yourdomain.comperiodically and scan for names you don't recognize. - Automated monitoring: free CT-monitoring services (Facebook's CT monitoring tool, cert-manager-style watchers, or a scheduled script hitting the crt.sh JSON API) can alert you the moment a new certificate appears — turning a discovery that used to take months into one that takes minutes.
This closes the loop that DigiNotar exposed: a mis-issued certificate can still happen, but it can no longer happen silently.
The takeaway
A TLS certificate proves domain control at a moment in time — nothing about intent, reputation, or safety. The chain of trust behind it depends on certificate authorities acting honestly, which is precisely the assumption Certificate Transparency was built to stop taking on faith: every certificate, from every CA, is now public, tamper-evident, and searchable within minutes of issuance. Read the padlock for what it actually says, not what it's often assumed to mean, and treat CT logs as one more real signal — alongside domain age, WHOIS history, and DNS records — when deciding whether a site is what it claims to be.