A TLS handshake is the negotiation that occurs at the start of every HTTPS connection, where the client and server authenticate each other (server always; client optionally), agree on a protocol version and cipher suite, and establish shared encryption keys.
In TLS 1.3 (the current standard), the handshake typically completes in one round-trip: the client sends a ClientHello with supported versions, cipher suites, and an ephemeral key share; the server responds with a ServerHello, its certificate chain, a signature proving it holds the private key, and a Finished message. The client verifies the certificate against trusted certificate authorities, sends its own Finished, and both sides derive traffic keys from the shared secret. Encrypted application data can then flow immediately.
When you visit https://example.com, after TCP connects, the TLS handshake begins. The server presents its SSL certificate for example.com, signed by a certificate authority. The browser verifies the certificate chain, performs key exchange, and confirms the server's identity. Only after this succeeds does the encrypted HTTPS session begin.
WarningA handshake failure—shown as "no cipher overlap" or certificate mismatch—often means the client and server cannot agree on protocol version or ciphers (e.g., legacy TLS 1.0 vs. a hardened server requiring TLS 1.2+), or the certificate doesn't match the domain requested via SNI. Always verify the TCP connection succeeded separately before blaming the TLS layer.
The TLS handshake is distinct from the TCP handshake that precedes it; the two are often confused but happen sequentially.