The padlock next to a web address makes two promises. You're talking to the site named in the address bar, not an impostor. And nobody in between, such as the café Wi-Fi or your internet provider, can read or change what's sent. A certificate makes the first promise, and without it the second is worthless.

It doesn't promise the site is honest. More on that at the end.

A certificate is an ID card for a website

A certificate is a small file a website sends your browser when it connects. Like an ID card, it holds a few facts and a signature from someone you trust:

  • The names it covers, such as rrjamal.ca and www.rrjamal.ca.
  • A public key, the site's half of a key pair (next section).
  • Who issued it: the certificate authority (CA) that checked the facts and signed it.
  • When it's valid: a start date and an expiry date.

You can see any site's certificate by clicking the padlock, or from a terminal:

echo | openssl s_client -connect rrjamal.ca:443 -servername rrjamal.ca 2>/dev/null \
  | openssl x509 -noout -subject -issuer -ext subjectAltName

subject=CN=rrjamal.ca
issuer=C=US, O=Amazon, CN=Amazon RSA 2048 M01
X509v3 Subject Alternative Name:
    DNS:rrjamal.ca, DNS:www.rrjamal.ca

The key pair behind it

Every certificate comes with two matching keys:

  • The public key is in the certificate, so anyone can see it.
  • The private key stays secret on the server and never leaves it.

They do two different jobs, and only one of them is about secrecy.

Signing proves who you're talking to. A signature is a short code made from a piece of data and the private key. Anyone with the public key can check that it matches the data, but only the private key could have made it. Signing hides nothing: like a handwritten signature on a letter, it shows who wrote it, and anyone can still read the letter.

Encryption keeps the conversation private, with a different key: a fresh secret that browser and server work out together. In today's TLS, the certificate's keys don't encrypt your data at all. Their job is making sure that secret is shared with the real site, not an impostor.

So a certificate on its own is worthless to a thief. It's public; every visitor gets a copy. Pretending to be the site takes the private key too, so the private key is the thing to protect.

What a connection looks like

The server doesn't sign each web request. It signs once, at the start of the connection, and everything after is protected by the shared secret:

sequenceDiagram
    participant B as Browser
    participant S as Server
    Note over B,S: The handshake, once per connection
    B->>S: random value + key share
    S->>B: random value + key share
    S->>B: certificate (public key inside)
    S->>B: SIGNATURE over everything above
    Note over B,S: Both compute the same secret<br/>from the key shares. It never<br/>crosses the network.
    Note over B,S: Every request and response after this
    B->>S: record: [encrypted HTTP request + auth tag]
    S->>B: record: [encrypted HTTP response + auth tag]

Inside each record is ordinary HTTP, cookies and all, encrypted.

So someone in the middle can't cut and paste their way in:

  • Relaying the real handshake leaves the secret between browser and server. Seeing the key shares isn't enough to work it out, so they can only pass along encrypted bytes.
  • Swapping in their own key share changes what was signed, so the signature no longer matches and the browser hangs up. Making a new one takes the private key.
  • Replaying an old signature fails too: it covers an old random value.
  • Tampering with a later request breaks its auth tag, a check made with the secret and the record's position. A changed, moved or copied record fails, and the connection closes.

SSL vs TLS

They're the same idea under two names. SSL was the original, from Netscape in the 1990s. When it was handed to the internet's standards body, it was renamed TLS:

Version Year Status
SSL 2.0 and 3.0 1995, 1996 Retired, insecure
TLS 1.0 and 1.1 1999, 2006 Retired in 2021
TLS 1.2 2008 Still widely used
TLS 1.3 2018 Current; what most connections use

Every connection today is TLS, but the old name stuck: "SSL certificate" and "TLS certificate" mean the same thing, and the same certificate works with TLS 1.2 and 1.3. HTTPS is ordinary web traffic (HTTP) sent through a TLS connection.

Who vouches for the site

Anyone can make a certificate that says "I am your bank". What makes one believable is the signature. A certificate authority only signs after checking that the requester really controls the name, usually by asking them to put a value on the website or in its DNS. Let's Encrypt, the largest CA, does this for free and automatically.

Your browser can't know every CA's signature, so trust works as a chain, ending at a root certificate it already has:

flowchart TB
    Root["Amazon Root CA 1<br/>root: built into your device"]
    Inter["Amazon RSA 2048 M01<br/>intermediate"]
    Site["rrjamal.ca<br/>the site's certificate"]
    Root -- "signed" --> Inter
    Inter -- "signed" --> Site
  • The site's certificate is signed by an intermediate.
  • The intermediate is signed by the root, whose private key the CA keeps offline.
  • The root ships with your operating system or browser. Apple, Microsoft, Mozilla and Google each run a program that decides which CAs make the list, and can remove a CA that breaks the rules.

If the chain reaches a root your browser trusts, the names match, and nothing has expired, you get the padlock. Otherwise you get a full-page warning.

Why certificates expire, and keep getting shorter

Certificates once lasted years. Now the maximum is 200 days, falling to 100 days in March 2027 and 47 days in March 2029, under rules agreed by the browsers and CAs. Let's Encrypt's last 90 days, with 45 days on the way.

The reason is damage control. If a private key leaks or a certificate is issued by mistake, cancelling it (revocation) doesn't reliably reach every browser. Expiry always does, so the shorter the life, the sooner a bad certificate stops working.

So renewal has to be automatic: tools such as Caddy or Certbot get a new certificate well before the old one expires, and services such as AWS Certificate Manager do it for you.

What a certificate doesn't do

  • It doesn't mean the site is safe. It proves the site controls its name, nothing more. A scam site on a lookalike name can get a padlock as easily as anyone.
  • It doesn't hide which site you visit. The contents of pages are private, but the site's name and address are visible to the network along the way.
  • It doesn't protect your data after it arrives. Once the site has it, keeping it safe is up to the site.

For a real setup, with every party involved and where each private key lives, see How HTTPS certificates work, and who does what.