How TLS Works: The HTTPS Handshake and Certificates

When a website's certificate expires, browsers show a full-page warning instead of the site. Your server is still running, but almost nobody gets through.

If the site uses HSTS, a header that tells browsers to insist on secure connections, it is worse. The HSTS standard says browsers should not even let users click past the error.

Picture a common setup. An online signing service lets landlords, tenants and small lenders sign rental and loan agreements in the browser. The setup is made up, but the problem is real.

One Saturday night, the certificate on the signing site expired. Someone had renewed it by hand a year earlier and set a calendar reminder. That person had since left the team.

For about three hours (made up), every signing session failed with a red warning. Several loan agreements missed a Monday payout deadline.

On Monday, the compliance lead asked two questions. Why did one file stop the whole business? And what protects a tenant's PAN, the Indian tax ID, between the phone and the server?

Both questions have the same answer: TLS. This guide explains how TLS works using that signing site, from the handshake to certificates to the fixes the team made.

TLS is the protocol that secures a connection, SSL is its older name, and HTTPS is ordinary web traffic sent inside TLS. People still say "SSL certificate", but modern sites use TLS.

A protocol is a set of rules two programs follow to talk. For HTTP/1.1 and HTTP/2, TLS runs on top of TCP, the layer that delivers bytes in order. HTTP/3 runs on QUIC instead, a newer transport built on UDP, a bare-bones layer that promises neither order nor delivery. QUIC carries the TLS 1.3 handshake inside itself.

TLS gives a connection three things. Confidentiality means nobody on the network can read the data. Integrity means nobody can change it without being caught. Authentication means you know which server you reached.

The IETF, the body that writes internet standards, has deprecated SSL 3.0 (2015) and TLS 1.0 and 1.1 (March 2021). In practice you meet TLS 1.2 and TLS 1.3, and new systems should prefer 1.3.

TLS works in two stages: first the server proves its identity and both sides agree secret keys, then all data flows encrypted with those keys. The first stage is called the handshake.

Think of a grain market. A new trader arrives to buy wheat. The sellers have never met him, so why would they deal with him?

He shows a member card from the traders' association, which every seller respects. The card carries his name and the secretary's signature. Sellers trust the association, so they trust the card.

Next, the trader and one seller agree private code words for prices, just for today's deal. People standing around hear them talk but cannot tell what "two gunny" means. Tomorrow they pick new words.

That is TLS in miniature. The member card is the certificate. The association is the certificate authority. The code words are the session keys, fresh for every connection.

Where the picture breaks: a member card can be copied, so TLS also makes the server prove it holds the matching private key. And TLS never speaks its code words aloud. Each side computes the same keys without sending them.

Two kinds of keys do two different jobs

Public key. A public key is one half of a key pair that anyone may see. Something signed with the matching private key can be checked with the public key. The signing site's certificate holds its public key.

Private key. The private key is the other half, and it stays on the server. Signing with it proves you own the certificate. If it leaks, an attacker can pretend to be you.

Session key. A session key is a shared secret used with symmetric encryption, where the same key both encrypts and decrypts. Symmetric encryption is fast, so it protects the actual agreement data.

Public-key maths runs only during the handshake. After that, a symmetric cipher protects the data. A cipher is the algorithm that scrambles and unscrambles it; AES-GCM and ChaCha20-Poly1305 are common ones. Both also detect any changed byte.

In a TLS 1.3 handshake, the browser and server swap key shares, one-time public values used to agree keys. Then the server sends and proves its certificate, and both confirm nothing was tampered with. A full handshake fits into one round trip.

A round trip is one message out and one reply back. From a tenant's phone to the signing site, say that takes 40 ms (made up). Fewer round trips means a faster first page.

Follow the boxes from top to bottom. Each box is one message, and the detail line says who sends it to whom. Notice where encryption starts.

Here is the same handshake in words, with what each step buys you.

1. 1

   ClientHello

   The browser lists the TLS versions and ciphers it supports and the site name it wants. It also sends a key share, a one-time public value for the key exchange explained below.

2. 2

   ServerHello

   The server picks a version and cipher and sends its own key share. Now each side can compute the same secret, though nobody on the wire ever saw it.

3. 3

   EncryptedExtensions

   From here on, messages are encrypted with keys from that secret. This message carries the remaining settings both sides agreed.

4. 4

   Certificate

   The server sends its certificate and the intermediate certificate above it. The browser will check this chain against its trusted roots.

5. 5

   CertificateVerify

   The server signs a summary of every handshake message so far with its private key. This proves it holds the key, not just a copy of the public certificate.

6. 6

   Finished, both ways

   Each side sends a check value computed over the whole handshake. If an attacker changed any message, the values will not match and the connection stops.

7. 7

   Application data

   The browser sends the signing request right after its Finished, encrypted with the session keys. The tenant sees the agreement page.

If the browser listed a key exchange the server supports but sent no key share for it, the server replies with a HelloRetryRequest asking for one. That costs one extra round trip.

Diffie-Hellman is the trick that lets two strangers agree a secret over an open line. Each side mixes its own private random number with the other's public value. Both land on the same result.

In a full handshake, those random numbers are used once and thrown away. The revised standard, RFC 9846, says clients and servers must not reuse a key share across connections.

This gives forward secrecy: if the site's private key leaks next year, traffic recorded today stays unreadable. Resumed connections have weaker rules, covered in the engineer sections.

TLS 1.3 cut a full handshake from two round trips to one, removed old and weak options, and encrypts the certificate. Its full handshake is faster, and the weak options are simply gone.

One major removal was static RSA key exchange. In that older method, the browser encrypted the secret with the server's long-term key. Anyone who later stole that key could decrypt every recorded session that used it.

AEAD, short for authenticated encryption with associated data, means one cipher both encrypts and checks for tampering. TLS 1.3 kept only ciphers of this kind, such as TLS_AES_256_GCM_SHA384.

Early data, also called 0-RTT, lets a returning browser send a request inside its very first message. The standard warns there are no guarantees against early data being replayed between connections. Replayed means an attacker resends a copy.

A TLS certificate holds domain names, a public key, validity dates, the issuer's name and the issuer's signature over all of it. The standard format is called X.509.

Open any HTTPS site's certificate in your browser by clicking the icon beside the address. These are the fields that matter.

• Subject Alternative Name: the domain names the certificate covers. Browsers match the address bar against this list; the old Common Name field must not be used for this (RFC 9525).
• Public key: the key that checks the server's CertificateVerify signature.
• Validity: a not-before and a not-after date. Outside them, the certificate is rejected.
• Issuer: the certificate authority that signed it.
• Basic constraints: a flag saying whether this certificate may sign other certificates. A website certificate has it off, so it cannot vouch for anyone else.
• Signature: the issuer's signature over the fields above, so no field can be changed without detection.

We tested the basic constraints rule with OpenSSL 3.0.13. A certificate signed by a website certificate failed with "invalid CA certificate".

The certificate is public. Anyone can download it, just as anyone can glance at the trader's member card. What only the site holds is the private key that matches it.

A browser trusts a certificate when it can follow a chain of signatures up to a root certificate it already holds. It also checks the name, the dates, and the server's proof of the private key.

PKI, short for public key infrastructure, is the whole system of CAs, certificates, rules and checks that makes this work.

Root CAs usually sign intermediate CAs, which sign everyday website certificates. Let's Encrypt, for example, keeps its root key offline and issues website certificates from intermediates.

Back in the grain market, a seller may not know the district office that issued the trader's card. But that office holds a letter signed by the state office, and every seller knows the state office.

The trust store is the list of root certificates that came with the phone, laptop or browser. Browser and operating system makers decide which roots go in. Mozilla, for example, requires audits before inclusion and at least once a year after.

Each check in the next diagram must pass. One failure is enough for the warning page the tenants saw that Saturday.

Revocation means a CA cancelling a certificate before it expires, usually after a key leak. CAs publish certificate revocation lists (CRLs), signed lists of cancelled certificates, defined in the X.509 standard.

The Online Certificate Status Protocol (OCSP), a live lookup, has been optional for public CAs since March 2024. In December 2024, ISRG, which runs Let's Encrypt, set 6 August 2025 as the date to turn off its OCSP service, citing user privacy.

For a normal website certificate, the CA checks that you control the domain, not who your company is. You prove control by placing a value the CA asks for on your website or in your DNS records.

ACME, the Automatic Certificate Management Environment, is the standard protocol that automates this (RFC 8555). An ACME client on your server requests a certificate, answers the CA's challenge and collects the result.

ACME Renewal Information (RFC 9773, June 2025) goes one step further. The CA can suggest a renewal window to your client, for example to spread out load or after a mass revocation.

Certificate Transparency adds a public check on the CAs themselves. Certificates are recorded in public logs that can only be added to. Anyone can watch those logs for certificates issued for their domains.

Chrome requires this for public certificates: an unlogged one fails to validate in versions that enforce the policy. After the outage, the team set up a watch on the logs for the signing site's domains.

Public certificate lifetimes are shrinking to 47 days

Public TLS certificates issued since 15 March 2026 can last at most 200 days. The CA/Browser Forum, the group of CAs and browser makers that sets these rules, voted this in April 2025.

The limit falls to 100 days from 15 March 2027 and to 47 days from 15 March 2029. The same ballot cuts how long a CA may reuse a domain check, down to 10 days by 2029.

That settled the first Monday question. A yearly calendar reminder failed once. At 47 days, someone would have to renew about eight times a year. Renewal has to be a job a machine runs.

You can check a TLS connection with Python's built-in ssl module: connect, let it verify the certificate, then read the version, cipher and expiry date. The team runs a script like this every morning.

import socket
import ssl
import sys
from datetime import datetime, timezone

HOST = sys.argv[1] if len(sys.argv) > 1 else "example.com"

ctx = ssl.create_default_context()
ctx.minimum_version = ssl.TLSVersion.TLSv1_2

with socket.create_connection((HOST, 443), timeout=5) as raw:
    with ctx.wrap_socket(raw, server_hostname=HOST) as tls:
        cert = tls.getpeercert()
        print(tls.version(), tls.cipher()[0])
        expires = datetime.fromtimestamp(
            ssl.cert_time_to_seconds(cert["notAfter"]), tz=timezone.utc)
        days_left = (expires - datetime.now(timezone.utc)).days
        print(f"Expires {expires:%Y-%m-%d}, {days_left} days left")
        if days_left < 30:
            print("Renew now")

Run it as python3 check_tls.py example.com. Against our local test server, Python 3.13.16 printed "TLSv1.3 TLS_AES_256_GCM_SHA384", then "Expires 2026-11-09, 19 days left" and "Renew now".

The create_default_context call does the important work. It loads the system's trusted roots and turns on both certificate and hostname checks. Since Python 3.10 it also refuses anything older than TLS 1.2.

So the minimum_version line repeats the default, but it makes the rule visible to reviewers. Since Python 3.13 the default context also applies stricter X.509 checks to certificate fields.

We hit this ourselves. Our first expired test certificate lacked an Authority Key Identifier field, and Python 3.13 rejected it for that before even checking the date.

Pause and predict: what happens if the server forgets the intermediate certificate? We ran the script against three broken servers, and once with its minimum raised to TLS 1.3. A test root CA we made locally stood in for a public one.

What just happened? Each failure stopped inside wrap_socket, before any data was sent. That is the point: a strict client catches the same mistakes a browser would, before your users do.

For a quick look without Python, this OpenSSL command prints who the certificate belongs to, who signed it and when it expires.

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -enddate

Expect three lines: subject=, issuer= and notAfter=, the expiry in GMT. On our test server it printed "notAfter=Nov 9 14:31:37 2026 GMT". This command only shows the certificate; it does not fail on errors, so use the script for pass or fail.

Public TLS usually ends at a load balancer or gateway, the front door that receives traffic and passes it to your servers. That box holds the public certificate. Traffic inside your network should be encrypted again, often with mutual TLS between services.

TLS termination means the point where encrypted traffic is decrypted. Ending it at the load balancer keeps public certificates in one place and lets that box route requests by their content.

Mutual TLS, or mTLS, means both sides show certificates. The signing service checks that a caller really is the load balancer, not some other program that got into the network.

In the diagram, look at the internal CA. It issues short-lived certificates only to the team's own services. No browser trusts it, and none needs to.

The team also turned on HSTS for the signing site. A max-age of 31536000 seconds tells browsers to use only HTTPS for one year, and includeSubDomains extends that to every subdomain.

Internal service certificates last 24 hours, a choice the team made. A stolen service certificate then goes stale by the next day, and renewal is already automatic.

Resumption lets a returning browser skip the certificate step by reusing a pre-shared key (PSK) from an earlier connection. It is faster, but its security depends on which mode is used.

If the resumed handshake also runs a fresh Diffie-Hellman exchange, forward secrecy holds. In PSK-only mode it does not: the standard says this mode loses forward secrecy for the application data.

Early data is weaker still. The standard says it is not forward secret, because it is encrypted only under keys from the earlier PSK. And there are no guarantees against replay between connections.

A post-quantum key share mixes today's elliptic-curve Diffie-Hellman with ML-KEM, a key-exchange method designed to withstand attacks from quantum computers. RFC 10024 (August 2026) standardises three such hybrids.

The aim of a hybrid is security as long as at least one of the two parts stays unbroken. The hybrid OpenSSL offers by default is named X25519MLKEM768.

Hybrids make the ClientHello bigger. An X25519MLKEM768 key share from the client is 1,216 bytes, against 32 bytes for plain X25519.

OpenSSL 3.5, released on 8 April 2025, offers X25519MLKEM768 and X25519 key shares by default. In our test, two Python builds on OpenSSL 3.5.7 negotiated X25519MLKEM768 with no configuration.

The same pair, forced down to TLS 1.2, used plain x25519. Hybrid key shares are a TLS 1.3 feature, which is one more reason to prefer 1.3.

The failures you can prevent yourself are mostly operational: expired certificates, missing intermediates, wrong names, leaked keys and verification switched off. Each one has a simple guard.

• Expired certificate. Guard: ACME renewal plus an expiry monitor that alerts a person, not a calendar.
• Missing intermediate. Guard: test every new certificate with a strict client, like the Python script, before going live.
• Wrong name. A new subdomain is not on the certificate. Guard: list every domain in config and check the list on deploy.
• Leaked private key. Guard: store keys in a secrets manager (a service that stores keys and gives them only to approved programs), limit who can read them, and revoke and reissue fast.
• Verification turned off in code. Guard: block it in code review and search the codebase for unverified contexts.
• Old versions left on. Guard: refuse anything older than TLS 1.2.

The compliance lead added one rule. Every agreement link sent by SMS or email must start with HTTPS, and the signing site must answer plain HTTP only with a redirect.

Explain it as two jobs, identity and key agreement, then place TLS in your design and show how you keep certificates alive.

1. 1

   State the two jobs

   TLS proves the server's identity with a certificate, then agrees session keys for fast symmetric encryption.

2. 2

   Walk the handshake

   Key shares in the hellos, then the encrypted certificate, the signature over the handshake and the two Finished messages. One round trip for a full TLS 1.3 handshake.

3. 3

   Explain the chain of trust

   Website certificate, intermediate, root in the trust store. Name the checks: signatures, name, dates and proof of the private key.

4. 4

   Place termination

   Say where public TLS ends, usually the load balancer, and how internal hops stay encrypted, often with mTLS and an internal CA.

5. 5

   Cover operations

   Automated renewal with ACME, expiry alerts, the full chain and keys in a secrets manager. Mention the 200-day limit falling to 47 days by 2029.

6. 6

   Name the trade-offs

   Early data saves a round trip but can be replayed, so allow it only for safe reads. Hybrid post-quantum key shares cost bigger hellos.