How SSL Certificates Work: The Chain of Trust Behind Every Padlock

You've seen the little padlock in your browser's address bar thousands of times — on your bank, your email, the page you're reading right now. Most people read it as a vague stamp of approval: this site is safe. It isn't quite that. The padlock means one specific thing happened correctly. Your browser checked a small signed file called a certificate, confirmed it was talking to the genuine owner of the domain in the address bar, and switched the connection to one that nobody in between can read.

That's worth understanding properly, because a certificate proves both more and less than most people assume. Here's what's actually going on behind the lock.

"SSL" is really TLS

First, a naming quirk worth clearing up. Almost everyone says SSL certificate, but SSL — Secure Sockets Layer — was retired years ago, and every version of it is now considered broken. The protocol your browser actually speaks is SSL's successor, TLS (Transport Layer Security), currently on version 1.3. The name "SSL" simply stuck, the way people still "dial" a number on a phone that hasn't had a dial in decades. When you read "SSL certificate," picture "the certificate that TLS uses." The file format has its own name too — X.509 — but that one rarely comes up in conversation.

What's actually inside a certificate

A certificate is a short, signed document that makes a single claim: this public key belongs to this domain name. You can open up any site's certificate with our SSL inspector and read the fields that matter:

• The domain names it covers, listed under Subject Alternative Name. One certificate can cover example.com, www.example.com, and a wildcard like *.example.com all at once.
• A public key — one half of a key pair. The matching private key never leaves the server and is never written into the certificate itself.
• The issuer — which authority vouched for it.
• A validity period, expressed as a "not before" and a "not after" date.
• A digital signature from the issuer. This is the part that makes the whole thing trustworthy.

That last field is the key to everything. Anyone can generate a file claiming to represent yourbank.com — it takes one command. What they can't do is get an authority your browser already trusts to sign it.

The chain of trust

This is the heart of how certificates work, and it's simpler than it first sounds.

Your computer and browser ship with a built-in list of a few hundred organisations they trust completely: the root certificate authorities. These are companies and non-profits — DigiCert, Sectigo, Let's Encrypt, and others — that are vetted heavily before their root certificate is allowed into the trust stores maintained by Apple, Microsoft, Google, and Mozilla.

A root authority almost never signs your website's certificate directly. Instead, it signs an intermediate certificate, and the intermediate signs your site's certificate — the leaf. So trust runs in a chain:

root  →  intermediate  →  your site (leaf)

When your browser receives your site's leaf certificate, it walks that chain upward. If it arrives at a root it already trusts, and every signature along the way checks out, the certificate is accepted. If the chain leads to a root the browser has never heard of, you get a warning instead.

Why the extra layer? Safety. A root certificate's private key is enormously valuable, so it's kept offline in a vault and used as little as possible. The intermediates do the day-to-day signing, and if one is ever compromised it can be revoked and replaced without disturbing the root that millions of devices depend on. One practical consequence falls out of this design: your server has to send the intermediate certificate alongside its own. Forget to, and some browsers can't complete the chain — the incomplete chain error we'll come back to.

The handshake, in the half-second before a page loads

So how does all this get used? Through a quick exchange called the TLS handshake. When you connect to a site on port 443 — the standard port for HTTPS — the server immediately presents its certificate, and your browser runs down a checklist:

• Does the certificate chain up to a root I trust?
• Is today's date inside its validity window?
• Does the domain in the address bar match a name on the certificate?
• Has it been revoked?

If every answer is right, the two sides use public-key cryptography to agree on a fresh, temporary key for this one session — a process (ECDHE) that gives the connection forward secrecy: even if the server's private key is stolen years later, today's recorded traffic still can't be decrypted. From that point the connection is encrypted, and the padlock appears. If you're hazy on how 443 differs from plain old port 80, the difference between the two ports is a useful detour.

Three flavours: DV, OV, and EV

Not every certificate vouches for the same thing. There are three validation levels:

• Domain Validated (DV) — the authority confirms you control the domain, and nothing more. Issued in seconds, usually free, and used by the overwhelming majority of sites.
• Organisation Validated (OV) — the authority also checks that a real, registered organisation stands behind the request.
• Extended Validation (EV) — a deeper vetting of the legal entity. EV used to paint a company's name in green in the address bar, but browsers removed that treatment years ago once research showed almost nobody noticed it. Today an EV certificate looks identical to a DV one to an ordinary visitor.

Here's the part that trips people up. A DV certificate — which is what sits behind most padlocks — says nothing whatsoever about whether a site is honest or safe. It proves only that whoever set the site up also controls the domain. A scammer can get a perfectly valid certificate for paypa1-secure.com in under a minute, and it will show the very same padlock your bank does. Hold on to that thought; we'll close on it.

How you actually get one

To issue you a certificate, an authority has to confirm you genuinely control the domain. The modern way is an automated challenge defined by a protocol called ACME: the authority asks you to place a specific token at a specific URL on your site (an HTTP-01 challenge), or a specific record in your DNS (a DNS-01 challenge), then checks for it. Pass, and the certificate is issued — no phone calls, no paperwork.

This is the quiet revolution behind the modern web. In 2015, Let's Encrypt launched, offering DV certificates for free and fully automated through ACME. Before that, certificates cost money and involved manual steps, so a great many sites simply skipped HTTPS altogether. Within a few years the encrypted share of web traffic went from a minority to nearly all of it. If you run a domain, you can also restrict which authorities are even allowed to issue for it using a CAA record, and every certificate ever issued is published in public Certificate Transparency logs — a system built to catch an authority that issues a certificate it never should have.

Certificates are getting much shorter

Certificates don't last long, and they're about to last a great deal less. A decade ago you could buy one valid for five years. That fell to three, then to roughly one, then to a hard ceiling of 398 days. As of March 2026 the maximum is 200 days, and the industry has agreed a schedule to keep cutting: 100 days in March 2027, and just 47 days by March 2029.

The logic is straightforward. A certificate is a standing promise, and the shorter the promise, the less damage a stolen key or a mis-issued certificate can do before it expires on its own. Short lifetimes also lean far less on revocation — which, as we're about to see, has never worked especially well. The trade-off is that renewing a certificate every few weeks by hand is impossible, so the new rules effectively make automation mandatory. The ACME tooling Let's Encrypt popularised is exactly what makes a 47-day certificate liveable.

When a certificate goes bad: revocation

Sometimes a certificate has to be killed before its expiry date — most urgently when its private key has been stolen. That's what revocation is for, and there have traditionally been two ways to check it.

A CRL (Certificate Revocation List) is exactly what it sounds like: a published list of revoked certificates that software downloads and checks against. OCSP (Online Certificate Status Protocol) was the newer idea — rather than download a whole list, your browser would ask the authority about one specific certificate in real time.

OCSP is now being switched off. Let's Encrypt shut its OCSP service down for good in August 2025, and the reason is a tidy illustration of how privacy problems hide in plumbing: every OCSP check told the certificate authority precisely which site a user was visiting, at the moment they visited it. At Let's Encrypt's scale that was billions of those signals a day. CRLs leak nothing of the sort, and short-lived certificates make the whole question matter less — a certificate that expires in a few weeks is a small risk even if it can't be cleanly revoked in the meantime.

The errors you'll actually run into

When something is wrong, browsers throw a full-page warning rather than a quiet note, because a broken certificate can mean a harmless misconfiguration — or an attacker. The usual culprits:

• Expired — the "not after" date has passed. By far the most common cause, and almost always a renewal that didn't happen.
• Name mismatch — the certificate is valid but doesn't list the exact domain you're visiting (often example.com works while www.example.com doesn't, or the reverse).
• Self-signed — the certificate signed itself instead of chaining to a trusted authority. Fine for internal testing, alarming on the public web.
• Untrusted issuer — the chain leads to a root your device doesn't carry.
• Incomplete chain — the leaf is fine, but the server didn't send the intermediate, so some clients fail to connect even while others succeed.

If you hit one of these, our SSL inspector lays out the full chain, the dates, and exactly which link is broken.

What the padlock proves — and what it doesn't

So, back to that padlock. Here's the accurate reading of it.

A valid certificate proves three things: you are connected to the domain shown in the address bar and not an impostor on the same network; the connection is encrypted, so nobody between you and the server can read it; and a recognised certificate authority confirmed that whoever holds the certificate controls that domain.

It proves none of these: that the site is safe, that the business behind it is legitimate, or that your data will be handled responsibly once it arrives. A phishing page on a freshly registered lookalike domain can carry a flawless padlock, because all the padlock ever promised was a secure line to that domain — it was never a judgement about the domain's character.

Understanding that one distinction is most of what certificates are good for. The padlock tells you the channel is sound. Whether the destination deserves your trust is still your call — and tools like our certificate inspector, the HSTS preload list, and Certificate Transparency logs are there to help you decide with more than a green icon to go on.