How the SSL and TLS handshake works

Overview

The SSL and TLS handshake is the conversation a browser and a server have before any encrypted data moves. It does three jobs in one trip: agree on which protocol version to use, verify that the server is who it claims to be, and agree on a shared secret without ever sending that secret across the wire. Nearly every "your connection is not private" error, handshake timeout, and cipher mismatch is a failure of one of these three jobs.

The steps in order

1. The client sends a ClientHello: supported TLS versions, cipher suites, and a random number for later key derivation.
2. The server replies with a ServerHello choosing one version and one cipher suite, sends its random, and presents its certificate chain.
3. The client checks the certificate: validity dates, hostname in the SAN list, signature from a CA the client trusts.
4. If the certificate is valid, the two sides run a key exchange to agree the same session key without transmitting it. In RSA suites the client encrypts a pre-master secret with the public key; in Diffie-Hellman suites both sides contribute and the result is forward secret.
5. Each side sends Finished messages, a hash of everything agreed so far, and encrypted application data can now flow.

What a cipher suite string says

Cipher suite names look intimidating but split into fields. For ECDHE-RSA-AES128-GCM-SHA256, the parts mean:

| Field | Example value | Role |

| ECDHE | ECDHE | Ephemeral elliptic-curve Diffie-Hellman key exchange, forward secret |

| RSA | RSA | Algorithm that signs authentication during key exchange |

| AES128-GCM | AES-128 with GCM | Symmetric block cipher and mode that encrypts the data |

| SHA256 | SHA-256 | Hash function used in the message authentication code |

"No shared cipher" is the browser equivalent of two people who cannot agree on a language. When you see it, the fix is usually on the server: re-enable an older cipher, or remove unnecessary TLS versions.

Differences in TLS 1.3

TLS 1.3 changes the handshake from a two-round-trip to a one-round-trip process for a new connection:

• The client sends its own key-share guess inside the ClientHello, so the server can answer with ServerHello, certificate, and encrypted keys in one return trip.
• Old symmetric ciphers such as CBC and the RSA key transport are removed. Ephemeral Diffie-Hellman is the only key exchange with RSA authentication still available.
• The client uses the guessed key share only when the server agrees; if a mismatch occurs, the two sides fall back to a full exchange, adding one extra round trip on that first connection only.

In practice

In the browser you can watch a handshake fail: curl -v https://example.com prints the ClientHello, the ServerHello, the certificate, and the negotiated TLS version and cipher, then "subject: CN=...". If the check fails, the output also names the reason; SSL certificate problem for trust failures, no peer certificate available when nothing is presented, and handshake failure usually for cipher by a version mismatch. Shared error references live in the SSL errors article, and certificate type differences live in the certificate types article.

Prevention

• Keep TLS 1.2 available for older visiting clients and enable TLS 1.3 for the rest.
• Set production servers to prefer TLS 1.3 and the GCM and CHACHA families when mutual version support allows.
• Set the certificate chain complete when an intermediate certificate is missing, so the handshake does not fail before encryption can start.