What is a TLS Handshake?

A TLS handshake is the negotiation process a client and server perform before exchanging encrypted data, in which they agree on a TLS version and cipher suite, verify the server’s certificate, and establish shared session keys.

A TLS handshake is the sequence of messages a client and server exchange to establish a secure connection. It negotiates the TLS version and cipher suite, authenticates the server (and optionally the client) using an X.509 certificate, and derives shared session keys, all before any application data is sent.

Key Takeaways

• TLS 1.3, defined in RFC 8446, reduced the handshake to a single round trip, down from two round trips in TLS 1.2, cutting connection setup latency roughly in half.
• The handshake’s core job is threefold: agree on cryptographic parameters, authenticate the server via its certificate, and derive session keys through a key exchange, most commonly ECDHE.
• Mutual TLS (mTLS) extends the standard handshake by also requiring the client to present a certificate, authenticating both sides of the connection.
• TLS 1.3 removed support for static RSA key exchange and older ciphers, making forward secrecy (via ephemeral Diffie-Hellman) mandatory rather than optional.
• A handshake fails immediately if the server’s certificate is expired, is not trusted by the client, or does not match the requested domain name (SNI mismatch).

What Happens During a TLS 1.3 Handshake, Step-by-Step?

1. ClientHello: the client sends the TLS versions and cipher suites it supports, along with a random value and a preliminary key share.
2. ServerHello: the server picks a TLS version and cipher suite from the client’s list and sends its own key share.
3. Certificate: the server sends its X.509 certificate chain so the client can verify its identity against a trusted CA.
4. CertificateVerify: the server proves it holds the private key matching its certificate by signing the handshake transcript so far.
5. Finished: both sides compute session keys from the exchanged key shares and confirm the handshake with a MAC over the transcript.
6. Application data: encrypted data now flows using the negotiated session keys, all within a single round trip from the client’s first message.

How is TLS 1.3 Different From TLS 1.2?

Aspect	TLS 1.2	TLS 1.3
Round trips to complete handshake	2	1 (0 with session resumption)
Static RSA key exchange	Supported	Removed
Forward secrecy	Optional	Mandatory (ephemeral Diffie-Hellman)
Cipher suite negotiation	Broad, includes weaker ciphers	Restricted to a small, modern set (e.g., AES-GCM, ChaCha20)

What is a TLS Handshake Failure and What Causes It?

A handshake failure means the client and server could not agree on parameters or could not validate each other’s identity, so no secure session is established.

• Certificate expired or not yet valid: the client rejects a certificate outside its notBefore/notAfter validity window.
• Untrusted issuer: the certificate chains to a CA not present in the client’s trust store.
• Hostname mismatch: the certificate’s Subject Alternative Name does not match the domain the client requested via SNI (Server Name Indication).
• Cipher suite mismatch: the client and server share no common, mutually supported cipher suite.

How Does Mutual TLS Change the Handshake?

Mutual TLS (mTLS) adds a CertificateRequest message from the server and a matching Certificate and CertificateVerify pair from the client, so both sides authenticate with an X.509 certificate rather than only the server. This is common in API-to-API, service mesh, and Zero Trust architectures where both endpoints need to prove identity before exchanging data.

How Encryption Consulting Helps

How Encryption Consulting HelpsCertSecure Manager issues and automates renewal for the TLS server and client certificates every handshake depends on, so expired or misconfigured certificates never cause a failed connection. Backed by ISO/IEC 27001:2022 and SOC 2 certified practices.

Frequently Asked Questions

How long does a TLS handshake take?

Under TLS 1.3, a full handshake completes in a single round trip between client and server, and a resumed session can complete in zero additional round trips. TLS 1.2 required two round trips, making TLS 1.3 noticeably faster to establish a connection.

What is the difference between a TLS handshake and an SSL handshake?

SSL is the deprecated predecessor to TLS; the last SSL version, SSL 3.0, was formally deprecated due to security flaws. The handshake process is functionally the same concept, but “TLS handshake” is the technically accurate term for any modern secure connection.

Why does a TLS handshake fail with a certificate error?

A handshake fails on a certificate error when the server’s certificate is expired, issued by a CA the client does not trust, or does not match the requested domain name. The client refuses to proceed until it can verify server identity.

What is Server Name Indication (SNI) and why does it matter in the handshake?

SNI lets a client specify which hostname it is connecting to during the ClientHello, before the server picks which certificate to present. This lets one IP address host multiple TLS-secured domains, each with its own certificate.

Keep Every TLS Handshake Running Smoothly

Take the next step CertSecure Manager automates certificate issuance, renewal, and deployment so your TLS handshakes never fail on an expired or misconfigured certificate. See CertSecure Manager in action.