What Is the TLS Handshake? The Beginner's Guide

CodexFuse Team · 2026-11-03T18:05:17.711Z · 11 min read min read

Every time your browser opens a page with a padlock icon, an invisible negotiation happens first: your browser and the server agree on an encryption method, the server proves it is who it claims to be, and both sides derive secret keys that encrypt everything after. That negotiation is the TLS handshake, and understanding it explains most of the certificate errors and "connection not secure" warnings you will ever see. One naming note said once and early: people still say "SSL handshake", but SSL is the retired ancestor — every current browser and server runs TLS, and TLS 1.3 does most of the work today. A security headers checker is the natural companion once you grasp the handshake, because most misconfigurations it flags are the handshake failing at a specific step.

What Is the TLS Handshake, Exactly?

A TLS handshake is the opening negotiation between a client and a server that establishes an encrypted, authenticated connection before any application data moves. The client proposes TLS versions and cipher suites in a ClientHello message, the server selects one and sends back its certificate, the two sides perform a key exchange that gives them a shared secret without ever sending it across the wire, and both derive the symmetric session keys that encrypt the rest of the conversation. In TLS 1.2 this takes two round-trips; in TLS 1.3, one.

The handshake has three jobs, and every explanation of how does tls handshake work comes down to them: negotiation (which protocol version and cipher suite both sides will use), authentication (the server proves its identity with an X.509 certificate signed by a trusted certificate authority), and key exchange (both sides create a shared secret that only they know). A Finished message at the end confirms nothing was tampered with along the way.

What Are the TLS Handshake Steps?

Here is one real handshake using TLS 1.3 (RFC 8446), the version most browsers negotiate by default in 2026. This numbered sequence is the snippet-shaped answer to "what are the TLS handshake steps":

1. ClientHello. The client sends a random value, the TLS versions and cipher suites it supports, and a key_share: its own half of a Diffie-Hellman key exchange for a group it is willing to use (commonly X25519 or P-256). Offering key material in the very first message — instead of waiting to be asked — is the biggest structural change from TLS 1.2.
2. ServerHello. The server picks a version and cipher suite and replies with its own key_share for the same group. Both sides can now compute the same shared secret independently, without either one sending that secret across the network.
3. EncryptedExtensions, Certificate, CertificateVerify. Every message from here on is encrypted under keys derived from that shared secret. The server sends its EncryptedExtensions, then its certificate chain, then a CertificateVerify message — a signature over the entire handshake using the private key that corresponds to the public key in the Certificate message (RFC 8446, Section 4.4.3).
4. Finished. Both sides send an encrypted hash of the handshake transcript. If either side's computed hash does not match, the connection dies — this is what proves nobody tampered with the negotiation.

The full exchange completes in a single round trip. That speed is the headline upgrade: on a 100 ms link, the handshake portion of connection setup drops from roughly 200 ms under TLS 1.2 to roughly 100 ms under TLS 1.3 (two round-trips vs one, per the round-trip figures sourced below).

What Happens in the TLS 1.2 Handshake?

The classic TLS 1.2 handshake (RFC 5246, published 2008) needs two round-trips before data can flow, and seeing its longer message dance explains why 1.3 cut it down. The client opens with ClientHello as usual, but the server's reply is a bundle: ServerHello, then its Certificate, then optionally a ServerKeyExchange carrying an ephemeral public key signed with the server's long-term private key, and finally a ServerHelloDone message telling the client the server's flight is over.

Only then does the client act: it sends its ClientKeyExchange (with key material that the server's long-term key protects), followed by its Finished message. The server answers with its own Finished message, and the encrypted session begins. Note the security consequence hidden in that older design: TLS 1.2 cipher suites that used static RSA key exchange let anyone holding the server's private key decrypt recorded past traffic. TLS 1.3 removed static RSA and static DH entirely, so every TLS 1.3 handshake is forward secret by construction.

TLS 1.2 vs TLS 1.3: What Actually Changed?

The tls 1.2 vs tls 1.3 handshake comparison is where beginners see why the protocol overhaul mattered. This table is the citable summary:

The five TLS 1.3 cipher suites are worth naming, because every other suite you will ever configure belongs to TLS 1.2: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_CCM_SHA256, and TLS_AES_128_CCM_8_SHA256 (the last two are for constrained devices, per the RFC 8446-based suite listings). The most commonly negotiated suite in the wild is TLS_AES_128_GCM_SHA256; AES-GCM is fastest on hardware with AES-NI acceleration, while ChaCha20-Poly1305 performs better on mobile devices without it. Note also that in TLS 1.3 the key exchange is negotiated separately from the cipher suite — unlike in TLS 1.2, the suite name no longer tells you which key-exchange algorithm was used.

Two lifecycle facts frame this table. First, TLS 1.0 and 1.1 are formally dead: browsers disabled them in 2020 (Firefox 74 shipped the switch-off on March 10, 2020; Chrome 84 followed on July 14, 2020) and the IETF deprecated them with RFC 8996 in March 2021. Second, TLS 1.3 itself got a maintenance update: RFC 9846, published in 2026, obsoletes RFC 8446 (the original TLS 1.3 spec) and RFC 5246 (TLS 1.2), among others — the protocol number did not change, but the document did.

How Do Cipher Suites and Key Exchange Work in the Handshake?

A cipher suite is just a named bundle of four decisions: how the key exchange happens, how the server authenticates, which bulk cipher encrypts the data, and which hash feeds the key derivation. Read a suite name left to right and it decodes itself — TLS_AES_128_GCM_SHA256 means the TLS protocol, AES with a 128-bit key in GCM mode for bulk encryption, and SHA-256 for the handshake's key-derivation function.

The key exchange is the clever part: it uses asymmetric cryptography once so that symmetric cryptography can do the fast work afterward. In TLS 1.3's ephemeral Diffie-Hellman exchange, each side combines its own private value with the other side's public key share to reach the same shared secret — anyone eavesdropping sees only the public halves and learns nothing. That is also why forward secrecy matters: because the Diffie-Hellman keys are ephemeral and discarded, a stolen server private key cannot be used later to decrypt traffic an attacker recorded today.

Session resumption is the handshake's shortcut lane, and it works differently per version. TLS 1.2 lets the client present a session ID or ticket and skip straight to Finished messages, cutting the handshake to one round trip. TLS 1.3 replaces both with pre-shared keys: after a handshake finishes, the server sends a NewSessionTicket carrying a key derived from that session, and the client presents it next time. The aggressive version is 0-RTT, where the client sends application data in its very first flight — but 0-RTT data is not forward secret and has no replay protection, so browsers only use it for idempotent, retry-safe requests.

Why Do TLS Handshakes Fail?

Any single step of the handshake can fail, and browsers map each failure to a specific error. This failure table is the diagnostic asset to bookmark — each row pairs the handshake step that breaks with the error you will actually see:

The intermediate-certificate row deserves emphasis because it is the most common production failure beginners hit: the end-entity certificate is perfectly valid, but the server only sends the leaf certificate instead of the leaf-plus-intermediate chain, so the client cannot build a path to a trusted root. The practical fix path is to check the site's certificate with an SSL certificate checker, which reports the full chain, expiry, and SAN coverage in one pass — exactly the three things the first three rows of this table need.

How Can I See a TLS Handshake Myself?

The fastest way to watch a handshake is OpenSSL's client, which prints the negotiated version and suite in its opening lines. Run this against any HTTPS site (replace the host with your own to debug it):

openssl s_client -connect example.com:443 -servername example.com -tls1_3

In the output, look for Protocol : TLSv1.3 and Cipher : TLS_AES_128_GCM_SHA256 — that is the exact output of steps 1 and 2 of the handshake, the version and cipher suite the two sides negotiated. The -servername flag sends the SNI extension from the failing row of the table above, which matters on any shared hosting where one IP serves many domains. Dropping -tls1_3 lets you test whether an old server still answers TLS 1.2, and if the connection dies immediately you have reproduced the "no shared version" failure row firsthand.

For total connection cost, add the transport layer: a full HTTPS setup costs the TCP handshake (about 1.5 round-trips) plus the TLS handshake (1–2 round-trips), so 2.5–3.5 round-trips elapse before the first HTTP byte is requested under TLS 1.2, versus about 2.5 under TLS 1.3. If you are tuning this on your own server, the Claude Code beginner guide is the lane for driving these probes and config edits through an AI coding agent.

What Is mTLS, and How Does It Extend the Handshake?

Mutual TLS (mTLS) extends the standard handshake by also requiring the client to present a certificate, authenticating both sides of the connection instead of only the server. Mechanically, the server sends a CertificateRequest message during its flight, and the client answers with its own Certificate and CertificateVerify pair before the session keys are finalized. This is the standard pattern inside zero-trust service meshes, where servers cannot afford to trust any client that merely reaches them. The sibling-lane line is drawn once: a full mTLS guide — when client certificates make sense, how to issue them, and where they fit in a service mesh — lives in what is mTLS; this page covers only the handshake step it adds.

Is the "SSL Handshake" the Same Thing?

Yes, in practice: "SSL handshake" is the legacy name for the same negotiation, and every modern use of the term refers to TLS. The actual SSL protocol versions are all retired — TLS 1.0 was SSL's direct successor — so documentation that says "SSL handshake" is describing the ClientHello-to-Finished flow covered above. One more sibling line, drawn once: the privacy of the handshake's own metadata — hiding the server name (SNI) so onlookers cannot see which site you are visiting — belongs to the queued Encrypted Client Hello lane, which covers a different problem (metadata privacy) than this page (the negotiation itself). The two are companions, never rivals.

Sources

The facts above were verified against these sources, all fetched on November 3, 2026: the host-tracker.com TLS handshake explainer (1.3 message sequence, 1.2-vs-1.3 comparison values, removed algorithms, RFC 8446 Section 4.4.3 wording); RFC 8446 on datatracker.ietf.org (key_share extension, Section 4.2.8); the Aruba HPE technical documentation citing the five RFC 8446 cipher suites; the Encryption Consulting cipher-suites page (CCM suites for constrained environments, forward-secrecy discussion); Azion's SSL/TLS handshake process page (round-trip arithmetic, updated April 2026); the Encryption Consulting TLS handshake explainer (1-RTT vs 2-RTT latency, failure causes); dev.to's "TLS Handshake Explained: How HTTPS Actually Works" (the three handshake jobs); pulsetic.com's ERR_SSL_VERSION_OR_CIPHER_MISMATCH error page (TLS 1.2 = RFC 5246/2008, every failure-to-error mapping, updated September 2026); rip.so's TLS 1.0 timeline (browser switch-off dates, published October 2026); the IETF history page for RFC 8996 (TLS 1.0/1.1 deprecation, 2021); rfc-editor.org's info page for RFC 9846 (2026, obsoletes 8446 and 5246); eco.com's TLS support article (TLS_AES_128_GCM_SHA256 as the most-negotiated suite, Cloudflare Radar adoption figures); and web443.com's cipher-suite selection guide (AES-GCM vs ChaCha20-Poly1305 hardware trade-off).

Frequently Asked Questions

What is the TLS handshake in simple terms?

It is the short negotiation your browser and a server run before any page data moves: they agree on a protocol version and cipher suite, the server proves its identity with a certificate, both sides derive shared secret keys, and a Finished message confirms nothing was tampered with. Everything after it is encrypted.

How many steps are in the TLS 1.3 handshake?

Four message flights complete it in one round trip: ClientHello (with key_share), ServerHello, the encrypted flight of EncryptedExtensions plus Certificate plus CertificateVerify, and Finished from both sides. TLS 1.2 needed six flights across two round trips.

What is the difference between the TLS 1.2 and TLS 1.3 handshakes?

TLS 1.3 completes the handshake in 1 round trip instead of 2, uses exactly 5 AEAD-only cipher suites, makes forward secrecy mandatory by removing static RSA/DH key exchange, encrypts the certificate flight, and forbids renegotiation — while TLS 1.2's longer message dance kept legacy algorithms and optional forward secrecy.

Why does the TLS handshake fail?

The most common causes are an expired certificate, a hostname the certificate does not cover, an untrusted or missing intermediate in the chain, or no TLS version or cipher suite both sides share. Each maps to a distinct browser error (ERR_CERT_DATE_INVALID, ERR_CERT_COMMON_NAME_INVALID, ERR_CERT_AUTHORITY_INVALID, or ERR_SSL_VERSION_OR_CIPHER_MISMATCH), which is why matching the error to the table in this guide is the fastest diagnostic.

Is TLS 1.3 always used today?

Nearly — Cloudflare Radar put roughly 80% of internet traffic on TLS 1.3 as of 2024, and every major browser negotiates it by default. Fallback to TLS 1.2 still happens with legacy servers, and TLS 1.0/1.1 were disabled in browsers in 2020 and formally deprecated by RFC 8996 in 2021, so a server offering only those will fail the handshake against any modern client.