How SSL Works

The padlock in the address bar is one of the most trusted symbols on the internet, and most people who see it every day could not say what it proves. This is what it proves, how it proves it, and the ways it goes wrong.

SSL, TLS, and why the old name stuck

SSL, Secure Sockets Layer, was Netscape's protocol from the 1990s. It was replaced by TLS, Transport Layer Security, in 1999, and every version of SSL has been broken and retired for years. What runs under the padlock today is TLS 1.2 or 1.3.

Everybody still says SSL. Certificate vendors sell "SSL certificates," hosting panels have an "SSL" tab, and this post is called what it is called so that people can find it. When you read SSL anywhere on this site, read TLS.

Three things TLS gives you

A connection protected by TLS has three properties, and they are worth keeping separate.

Confidentiality. Nobody between the browser and the server can read what passes between them. Your ISP, the coffee shop's router, anyone on the path sees only that a connection exists and roughly how much data moved.

Integrity. Nobody on the path can change what passes between them without it being detected. No injected ads, no swapped download.

Authentication. The browser has good reason to believe the server it reached is genuinely the one that controls example.com. Something sitting in the middle and pretending would fail this check.

The third one is what the certificate is for. Encryption without authentication is a private conversation with a stranger.

What a certificate is

A certificate is a small signed document. It contains a public key, the domain names the key may be used for, a validity window with a start and an end, the identity of the organisation that issued it, and that organisation's signature over the whole thing.

The public half of a key pair lives in the certificate. The private half lives on your server and never leaves it. Anyone can use the public key to encrypt something only the private key can decrypt, and to verify signatures only the private key could have made. That is how a server proves it holds the private key that goes with the certificate it presented.

The signature is the part that makes it trustworthy. Anyone can generate a key pair and write a certificate claiming to be example.com. What they cannot do is get a certificate authority the browser trusts to sign it.

The chain of trust

Browsers and operating systems ship with a root store: a few dozen certificate authorities, represented by a couple of hundred root certificates, whose signatures they will accept. Getting into that list takes years of audits, and being thrown out of it, which has happened to several, is a corporate death sentence.

Root certificates are too valuable to use directly, so authorities keep them offline and sign intermediate certificates, which do the day-to-day issuing. The certificate your server presents was signed by an intermediate, which was signed by a root the browser already knows.

When a browser connects, the server sends its own certificate plus the intermediates. The browser follows the signatures upward until it reaches something in its root store. If the chain reaches a trusted root, every signature checks out, the domain name matches, and today's date falls inside the validity window, the padlock appears.

Every one of those conditions is a way to fail. The chain is the one people forget. A server configured with only its own certificate and no intermediate works fine in browsers that happen to have that intermediate cached, and fails in everything else, which is why a site can look fine to the developer and broken to a customer.

Proving you own the domain

Before an authority will sign a certificate for example.com, it needs evidence you control it. For the ordinary domain validated certificate, that evidence is one of:

• serving a specific file at http://example.com/.well-known/acme-challenge/...,
• publishing a specific TXT record in the domain's DNS,
• answering a TLS connection with a specific temporary certificate.

Let's Encrypt automated this with the ACME protocol in 2015, made certificates free, and changed the default from "most sites are unencrypted" to "nearly all sites are encrypted" within a few years. A certbot or acme.sh job on your server, or the built-in support in Caddy, most CDNs and most hosting platforms, requests, proves and installs a certificate with no human involved.

Organisation validated and extended validation certificates add checks on the legal entity behind the domain. Browsers stopped displaying the company name for EV certificates years ago, having found that users neither noticed nor cared, and for most sites DV is the right choice.

A certificate can cover several names through its subject alternative names, and a wildcard certificate for *.example.com covers every direct subdomain. Wildcards can only be issued through the DNS challenge, because you have to prove control of the whole zone.

The handshake

When a browser opens a TLS 1.3 connection, roughly this happens:

1. The browser sends a ClientHello: the TLS versions and cipher suites it supports, a random value, and its half of a key exchange.
2. The server replies with a ServerHello picking the version and cipher, its own random value and its half of the key exchange, then sends its certificate chain and a signature made with its private key over the handshake so far.
3. The browser verifies the chain against its root store, checks the name and the dates, and verifies the signature. If everything holds, both sides derive the same session keys from the exchanged halves, without those keys ever crossing the wire.
4. Everything after this is encrypted with the session keys.

TLS 1.3 does this in one round trip, and can resume a recent session in zero. TLS 1.2 took two. The difference is a few tens of milliseconds per new connection, and it is why TLS stopped being the performance cost it was once believed to be.

One consequence deserves a mention. The session keys are fresh for every connection and are thrown away afterwards. Even if the server's private key leaks next year, recordings of today's traffic cannot be decrypted with it. This is called forward secrecy, and it is standard in TLS 1.3.

Why certificates keep getting shorter

Certificates used to last five years, then three, then two, then a little over one. Let's Encrypt issued them for 90 days from the start, on the argument that a short lifetime limits the damage from a stolen key and forces everyone to automate renewal.

The industry has followed. In 2025 the CA/Browser Forum, the body where authorities and browser makers set the rules, voted to bring the maximum lifetime down in steps: 200 days from March 2026, 100 days from March 2027, and 47 days from March 2029. Let's Encrypt already offers six-day certificates for those who want them.

The practical meaning is that manual renewal is over. Any certificate you have to remember to renew will, eventually, expire on a weekend. Automation is the only way to run this, and automation breaks quietly, which is why something outside your infrastructure should be checking the certificate visitors are actually served and counting the days.

The errors you will meet

In roughly descending order of how often they cause an outage:

Expired. The validity window ended. Every browser refuses the connection with a full-page warning. Renewal automation failed, or the renewed certificate was never loaded into the running service, or a CDN in front of the origin is still serving the old one.

Name mismatch. The certificate is valid, for a different name. Usually www.example.com served with a certificate for example.com, or a new subdomain that was never added to the SAN list. Chrome reports this as NET::ERR_CERT_COMMON_NAME_INVALID.

Incomplete chain. The intermediate was not sent. Works in some browsers, fails in others, fails in most command-line tools and most monitoring, and produces the least reproducible bug reports of anything in this list.

Untrusted issuer. Self-signed, or signed by an internal authority the visitor's machine does not have. Fine on a corporate intranet with the root installed, a wall for everyone else.

Mixed content. The page is over HTTPS but loads a script or image over plain HTTP. Browsers block the script and downgrade the padlock.

Clock skew. The visitor's clock is wrong, so a valid certificate appears to be from the future or the past. Rare, and impossible to fix from your side.

Revoked. The authority withdrew the certificate, usually because the key was compromised or the domain changed hands. Browsers check this inconsistently, which is one of the arguments for short lifetimes.

Barkme counts any TLS failure as down, because a visitor sees exactly that: a page that will not open. Every verified domain also gets its certificate checked from outside once a day, with warnings at 30, 14, 7 and 1 day before it expires, because expiry is the one failure on this list that is entirely predictable.

The layer beneath this one, the step that finds the server in the first place, is how DNS works.