How TLS and HTTPS Work — From Handshake to Encryption

Every time your browser shows a padlock icon, a sophisticated cryptographic protocol has already run in the background — usually in under 100 milliseconds. TLS is one of the most well-engineered security systems in use today, and understanding it pays dividends when you're debugging certificate errors, configuring servers, or evaluating security claims.

TLS vs. SSL: Clearing Up the Naming

SSL (Secure Sockets Layer) is the older protocol. It went through versions 1.0, 2.0, and 3.0 before being renamed TLS (Transport Layer Security) at version 1.0 in 1999. SSL 2.0 and 3.0 are broken and disabled everywhere. TLS 1.0 and 1.1 are deprecated. TLS 1.2 and 1.3 are what's actually in use.

TLS 1.3 (published as RFC 8446 in 2018) removed weak algorithms, simplified the handshake, and reduced round trips. When people say "SSL" in casual conversation, they almost always mean TLS. The terms are used interchangeably but only TLS is current.

The TLS 1.3 Handshake, Step by Step

The TLS handshake establishes a shared encryption key between the client and server without ever transmitting that key over the network.

Step 1 — ClientHello Your browser sends a message listing the TLS version it supports, a random value (client_random), and the cipher suites it supports (e.g. TLS_AES_256_GCM_SHA384). In TLS 1.3, the client also includes a "key share" — it picks a few likely key exchange algorithms and pre-generates public keys for each, sending them speculatively to save a round trip.

Step 2 — ServerHello The server picks the cipher suite, sends its own server_random, and selects one of the key shares. At this point, both sides can compute the same session key independently using Diffie-Hellman math — the key was never transmitted.

Step 3 — Certificate The server sends its certificate. This is a public document that contains the server's public key and is signed by a Certificate Authority. Everything from here is already encrypted with the session key derived in the previous step.

Step 4 — CertificateVerify and Finished The server signs a transcript of the entire handshake with its private key, proving it owns the certificate. The client verifies this signature. Both sides exchange Finished messages containing a MAC of the full handshake transcript — if anything was tampered with in transit, this check fails.

The entire TLS 1.3 handshake takes 1 round trip (down from 2 in TLS 1.2). Resumed sessions can use 0-RTT data, sending application data in the first message.

Certificate Chains

A TLS certificate isn't just one piece — it's a chain.

Leaf certificate: Your site's certificate. Contains your domain name and public key.
Intermediate certificate(s): Signed by the root CA. Root CAs don't sign leaf certs directly to limit exposure if an intermediate is compromised.
Root certificate: Self-signed by the CA. Trusted by your OS/browser by default.

Your browser walks the chain from your site's cert up to a root it already trusts. If any link in the chain is invalid, the connection fails. This is why forgetting to include the intermediate certificate when configuring your web server causes errors — your browser may not be able to build the chain.

You can inspect a certificate chain in browser DevTools: click the padlock, then "Certificate" (Chrome) or "More Information > View Certificate" (Firefox). You'll see each certificate in the chain.

How Your Browser Verifies a Certificate

When your browser receives a certificate for example.com, it checks several things:

Domain match: Does the Common Name or Subject Alternative Name field match the hostname? Wildcards like *.example.com are allowed.
Validity period: Is today between Not Before and Not After?
Chain of trust: Does each certificate in the chain have a valid signature from the next?
Revocation: Has the certificate been revoked? This is checked via OCSP (Online Certificate Status Protocol) or by consulting a CRL (Certificate Revocation List).
CT logs: Is the certificate in the Certificate Transparency logs? More on this below.

If any check fails, you see the red warning. The error codes (ERR_CERT_COMMON_NAME_INVALID, ERR_CERT_DATE_INVALID, etc.) directly correspond to which check failed.

Certificate Transparency

Since 2018, all publicly trusted certificates must be logged in Certificate Transparency (CT) logs — append-only public databases. This means every certificate issued for yourbank.com is publicly visible. Anyone can monitor CT logs for certificates issued for their domains, making it very hard for a rogue CA to issue a secret certificate.

You can search CT logs at crt.sh. If you own a domain and want alerts when new certificates are issued, services like Facebook's Certificate Transparency monitoring will notify you. This is a genuine security win — it's how unauthorized certificate issuance gets caught.

HSTS: Forcing HTTPS After the First Visit

HTTP Strict Transport Security (HSTS) tells browsers that your site should only be accessed over HTTPS, for a specified period:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Once a browser has seen this header, it will refuse to connect to your site over HTTP — even if the user types http:// — until the max-age expires. The preload directive gets your domain added to a browser-maintained list that enforces HTTPS before the first visit.

HSTS prevents a class of attacks where someone intercepts the initial HTTP request before the redirect to HTTPS. But there's a catch: if you accidentally set a very long max-age and then need to revert to HTTP (e.g. your cert lapses), users will be locked out. Start with a short max-age, verify everything works, then extend it.

Mixed Content

Mixed content warnings appear when an HTTPS page loads resources (images, scripts, stylesheets) over HTTP. Browsers block active mixed content (scripts, iframes) entirely and often warn on passive mixed content (images). If your site shows a padlock with a warning triangle, this is usually the cause. Check the browser console — it'll identify the offending resources.

Let's Encrypt and Automated Certificates

Before Let's Encrypt (launched 2016), getting a TLS certificate meant paying a CA, completing manual verification, and renewing annually. Let's Encrypt made certificates free and automated via the ACME protocol.

With Certbot or built-in server support (Caddy does this automatically), your server proves domain ownership by either serving a specific file over HTTP or creating a DNS record, then receives a 90-day certificate. Renewal happens automatically. This is why HTTPS is now essentially free — the barrier was cost and friction, not technical capability.

TLS is deeply connected to the hashing and public key infrastructure we covered elsewhere. If you want to understand how SHA-256 and digital signatures play into the certificate verification steps, Hashing Algorithms Guide and Public Key Cryptography Explained fill in those layers.

The Hash Generator tool lets you generate SHA-256 and other hashes to explore the algorithms that underpin TLS. The Base64 Encoder is useful when working with PEM certificate files, which are base64-encoded DER data.

TLS 1.3 is a well-designed protocol — the engineers who built it learned decades of hard lessons from SSL's failures. When you configure a new server, enforcing TLS 1.3 minimum and setting HSTS correctly gives you solid protection against most network-level attacks.