How SSL/TLS Certificates Work

The padlock in your browser's address bar rests on a quiet piece of machinery: the SSL/TLS certificate. It does two jobs at once — encrypting your connection and proving you are really talking to the site you think you are. Here is how that works, without the jargon.

SSL, TLS, HTTPS — the names

First, the terminology. SSL is the original protocol; TLS is its modern successor and what everyone actually uses today, though "SSL certificate" stuck as the common name. HTTPS is simply HTTP running inside a TLS-encrypted connection. When people say "SSL certificate" they almost always mean a TLS certificate. We will too.

Two jobs: encryption and identity

A certificate secures a connection in two distinct ways, and people usually only think of the first:

• Encryption. It scrambles the traffic between your browser and the server so nobody in between — your ISP, the café Wi-Fi, an attacker on the network — can read or tamper with it.
• Identity. It proves the server really is yourbank.com and not an impostor. Encryption alone is useless if you are encrypting a conversation with a fraudster.

The second job is the subtle one, and it is where the certificate authority system comes in.

The chain of trust

Your browser cannot personally know every website. Instead it trusts a small set of Certificate Authorities (CAs) — organisations whose job is to verify identities and issue certificates. The logic is a chain:

• Your browser ships with a built-in list of trusted root CAs.
• A root CA vouches for intermediate CAs.
• An intermediate issues the certificate for an individual site.

When you connect, the server presents its certificate and the intermediates linking it back to a trusted root. Your browser follows that chain; if it reaches a root it trusts and every link checks out, the padlock appears. A common real-world failure is a server that forgets to send the intermediate certificate — the site's own certificate is fine, but the chain is broken, so browsers reject it.

The handshake, simplified

When you open an HTTPS site, browser and server perform a TLS handshake: the server proves it owns the certificate's private key, the two sides agree on encryption keys for this session, and from then on everything is encrypted. It happens in milliseconds, invisibly, before the page loads. Modern TLS does this efficiently enough that HTTPS is no longer a meaningful speed penalty — and HTTP/2 and HTTP/3, which most sites now use, require it.

Validation levels and expiry

Certificates come in tiers. Domain Validation (DV) just proves you control the domain and is issued automatically and free (this is what Let's Encrypt popularised). Organisation and Extended Validation additionally vet the legal entity. For most sites, free DV certificates are perfectly sufficient — the encryption is identical; only the identity vetting differs.

Every certificate has an expiry date, and shorter lifespans are the trend — renewals now measured in weeks rather than years. An expired certificate throws a scary full-page browser warning that drives visitors away instantly, so renewal is usually automated. A lapsed auto-renewal is one of the most common ways a healthy site suddenly looks "hacked" to visitors.

Check before it bites

Certificate problems are invisible until a visitor hits the warning page — by which point you have already lost them. The things worth checking: that the certificate is valid and not expired, that the full chain (including intermediates) is present, and that it covers the exact hostname people use.

Inspecting a site's certificate to see its issuer, expiry date and chain, checking the overall health of the domain's DNS, and reading the security-related response headers a site sends all run from your browser. Make a habit of checking expiry and chain after any server change, and you will catch a broken or soon-to-lapse certificate before your visitors — and the padlock — do.