TLS Handshake Explained

When you open an HTTPS website, the browser does more than simply send an HTTP request to a server. Before application data can be exchanged securely, the client and server need to agree on cryptographic parameters, authenticate the server, and establish shared session keys. This process is called the TLS handshake.

TLS stands for Transport Layer Security. It protects application protocols such as HTTP by providing encryption, integrity protection, and authentication. HTTPS is essentially HTTP transported over a TLS-protected connection.

The exact handshake depends on the TLS version and the negotiated features. TLS 1.2 and TLS 1.3 use different handshake designs, with TLS 1.3 reducing the number of round trips and removing several older cryptographic mechanisms.

What Is a TLS Handshake?

A TLS handshake is the initial protocol exchange used to establish the security parameters for a TLS connection. During the handshake, the client and server negotiate a TLS version and cryptographic parameters, authenticate the server using its certificate, perform key exchange, and derive symmetric keys for protecting application data.

The handshake is important because the client and server normally need to communicate securely before they have established shared encryption keys. Public-key cryptography and digital signatures help solve the authentication and key-establishment problem, while symmetric cryptography is then used for the actual application data.

What Does TLS Provide?

TLS does not guarantee that the application itself is secure. A website can use a correctly configured TLS connection while still containing authentication flaws, injection vulnerabilities, insecure business logic, or other application-level problems.

Why Does HTTPS Need a Handshake?

A browser cannot simply encrypt an HTTPS request with a key that it already knows. The browser and server need to establish a shared secret securely, and the browser also needs evidence that it is communicating with the intended server rather than an attacker.

The TLS handshake solves these problems through a combination of negotiation, certificates, digital signatures, and ephemeral key exchange.

The Main Participants

The certificate authority is not normally involved in every live TLS handshake. Its role is primarily to issue certificates and establish a chain of trust. The client validates the server certificate against trusted roots already available in its trust store.

TLS Handshake at a High Level

Although the exact messages vary by TLS version, a modern TLS connection generally involves these logical stages: the client proposes supported parameters, the server selects compatible parameters, the server proves its identity, the client and server perform key exchange, and both sides derive keys used to protect application data.

• Client and server negotiate compatible TLS parameters.
• The server provides its certificate and related authentication information.
• The client validates the server certificate.
• The client and server establish shared keying material.
• Both sides derive symmetric traffic keys.
• The handshake establishes that subsequent records can be protected.
• Application data such as HTTP requests and responses can then be exchanged.

ClientHello

The TLS handshake begins with a ClientHello message. It contains information about what the client supports and what it is requesting from the server.

Server Name Indication

Server Name Indication, or SNI, is a TLS extension that allows a client to indicate the hostname it is connecting to during the handshake.

SNI is particularly important when multiple HTTPS websites share the same IP address. The server can use the requested hostname to select the appropriate certificate and TLS configuration.

Without the necessary hostname information, a server hosting many domains on one address may not know which certificate should be presented for the connection.

ServerHello

The ServerHello tells the client which compatible parameters the server selected. The exact contents differ between TLS versions, but the general purpose is to establish the parameters both sides will use.

In TLS 1.3, the server selects a TLS version and cipher suite while key exchange information is handled through extensions. TLS 1.3 significantly simplifies the set of available cryptographic choices compared with older versions.

What Is a Cipher Suite?

A cipher suite identifies cryptographic algorithms and parameters used by a TLS connection. The exact meaning of a cipher suite name depends on the TLS version.

TLS_AES_256_GCM_SHA384

For TLS 1.3, a cipher suite primarily identifies the authenticated encryption algorithm and hash function. Key exchange and authentication mechanisms are negotiated separately.

This is different from TLS 1.2, where cipher suite names describe a larger combination of key exchange, authentication, symmetric encryption, and hashing components.

TLS 1.2 Cipher Suites

TLS 1.2 cipher suite names historically included information about key exchange, authentication, encryption, and message authentication. For example, a TLS 1.2 suite might indicate an ECDHE key exchange, RSA authentication, AES-GCM encryption, and SHA-256.

This made TLS 1.2 cipher suite names more complex. It also means that comparing a TLS 1.2 cipher suite directly with a TLS 1.3 cipher suite by name can be misleading because the negotiated components are represented differently.

The Server Certificate

One of the most important parts of the TLS handshake is the server's certificate. An HTTPS certificate contains information that allows the client to associate a public key with a domain identity.

The certificate is digitally signed by a certificate authority or by another certificate in a trusted chain. The client uses the signature and certificate chain to determine whether the certificate can be trusted.

Why Does the Certificate Prove the Server's Identity?

The certificate itself does not magically prove identity. Trust comes from the certificate chain and the client's trust store. A trusted certificate authority has issued the certificate for the relevant identity, and the server must also prove possession of the corresponding private key during the handshake.

This distinction matters because anyone can generate a self-signed certificate containing example.com as a subject. A normal browser will not trust that certificate simply because the hostname appears in it.

Certificate Validation

Before accepting the server as authenticated, the client performs several certificate checks. The exact validation process depends on the implementation and configuration, but common checks include certificate chain validation, hostname matching, validity dates, and signature verification.

• The certificate chain leads to a trusted root or otherwise trusted anchor.
• The certificate is currently within its validity period.
• The requested hostname is covered by the certificate.
• Certificate signatures are valid.
• The certificate is permitted for the intended usage.
• Additional revocation or policy checks may be performed depending on the client.

Subject Alternative Name

Modern TLS hostname validation relies primarily on the Subject Alternative Name, or SAN, extension. A certificate can contain multiple DNS names, allowing one certificate to cover several hostnames.

DNS:example.com
DNS:www.example.com
DNS:api.example.com

The Certificate Chain

A server certificate is commonly part of a certificate chain. The leaf certificate is issued by an intermediate certificate authority, which ultimately chains to a trusted root certificate.

The server normally sends the leaf certificate and the necessary intermediate certificates. The client uses its own trust store for trusted root certificates.

Why Root Certificates Are Usually Not Sent by the Server

The client already has a collection of trusted root certificates in its operating system, browser, or application trust store. Sending the root certificate from the server is therefore generally unnecessary.

The server should normally provide the intermediate certificates needed to connect the leaf certificate to a trusted root. A missing intermediate can cause certificate validation failures even when the leaf certificate itself is valid.

Public-Key Cryptography in the Handshake

TLS uses asymmetric cryptography for authentication and key establishment, but it does not normally use public-key encryption to encrypt all HTTPS traffic. Public-key operations are relatively expensive compared with symmetric encryption.

Once the handshake establishes shared symmetric keys, TLS uses authenticated encryption to protect application data efficiently.

Ephemeral Key Exchange

Modern TLS commonly uses ephemeral Diffie-Hellman key exchange, usually through elliptic-curve groups such as X25519 or other supported groups. The client and server exchange public key material and independently derive shared secret material.

The important property is that the shared secret does not have to be transmitted directly over the network. Both parties can calculate compatible secret material from their private and public key components.

Forward Secrecy

Ephemeral key exchange can provide forward secrecy. This means that compromising a server's long-term private authentication key later should not by itself allow an attacker to decrypt previously recorded sessions protected with independently generated ephemeral session keys.

Forward secrecy is one reason modern TLS configurations favor ephemeral key exchange instead of older approaches that directly used the server's long-term private key to establish session secrets.

Digital Signatures in the Handshake

The server certificate contains a public key, but the client also needs evidence that the server actually controls the corresponding private key. TLS can use a digital signature to authenticate the server's participation in the handshake.

The client verifies the signature using the public key associated with the trusted certificate. This connects possession of the private key with the identity represented by the certificate.

Certificate Authentication vs Key Exchange

These are related but different concepts. The certificate authenticates the server's public key and identity, while the key exchange establishes shared secret material used to derive traffic keys.

TLS 1.2 Handshake

TLS 1.2 is still important for understanding existing infrastructure, although TLS 1.3 is preferred when supported. A typical full TLS 1.2 handshake involves a ClientHello, ServerHello, certificate messages, key exchange messages, and ChangeCipherSpec and Finished messages.

The exact message sequence depends on the selected cipher suite. For example, an ECDHE-based handshake differs from older RSA key-exchange configurations.

TLS 1.2 ClientHello and ServerHello

The client begins with ClientHello, advertising supported protocol versions, cipher suites, extensions, and other capabilities. The server responds with ServerHello, selecting compatible parameters.

The server then sends the certificate and, when required by the selected key exchange, additional key-exchange information. The server can also request a client certificate when mutual TLS is configured.

TLS 1.2 ServerKeyExchange

For common ECDHE-based TLS 1.2 configurations, the server sends parameters needed for ephemeral key exchange in a ServerKeyExchange message. The server signs those parameters so the client can verify that they came from the holder of the certificate's private key.

Not every TLS 1.2 cipher suite uses ServerKeyExchange in the same way. The exact message sequence depends on the negotiated algorithms.

TLS 1.2 ClientKeyExchange

The client sends its key-exchange contribution in ClientKeyExchange. In an ECDHE exchange, both sides now have enough information to derive the same shared secret without transmitting that secret directly.

TLS 1.2 ChangeCipherSpec and Finished

After the necessary key material has been established, TLS 1.2 uses ChangeCipherSpec to indicate a transition to the negotiated protected state. Finished messages provide cryptographic confirmation of the handshake.

The Finished message is important because it allows each side to verify that the handshake transcript has not been altered and that both parties derived compatible keying material.

TLS 1.3 Handshake

TLS 1.3 redesigned the handshake to reduce latency and remove older cryptographic mechanisms. A full TLS 1.3 handshake can generally establish the connection with fewer round trips than a typical full TLS 1.2 handshake.

TLS 1.3 also requires modern ephemeral key exchange and authenticated encryption algorithms. Older mechanisms such as static RSA key exchange and several legacy cipher constructions were removed from the protocol.

TLS 1.3 ClientHello

The TLS 1.3 ClientHello includes the client's supported versions, cipher suites, extensions, and key-share information. The key-share extension allows the client to provide key-exchange material as part of the initial message.

This contributes to TLS 1.3's lower handshake latency because the server can respond with its selected parameters and key-exchange information without first requesting another round of negotiation.

TLS 1.3 ServerHello

The server responds with its selected parameters and key-share information. After the ServerHello, both sides can derive handshake traffic keys.

Several subsequent handshake messages in TLS 1.3 are encrypted using keys derived from the key exchange, which improves confidentiality for parts of the handshake compared with older protocol versions.

TLS 1.3 EncryptedExtensions

EncryptedExtensions contains additional negotiated extensions that are relevant to the established connection. Because this message occurs after the initial key exchange, it is protected by handshake encryption.

TLS 1.3 Certificate and CertificateVerify

The server can send its certificate chain in the Certificate message. CertificateVerify contains a digital signature that proves control of the private key corresponding to the certificate and authenticates the relevant handshake transcript.

The client verifies both the certificate chain and the CertificateVerify signature before accepting the server as authenticated.

TLS 1.3 Finished

The Finished message provides cryptographic confirmation of the handshake. It is calculated using keying material derived during the handshake and incorporates the handshake transcript.

This allows each side to verify that the handshake has been completed consistently and that the exchanged messages have not been modified without detection.

TLS 1.2 vs TLS 1.3

What Is 0-RTT in TLS 1.3?

TLS 1.3 supports 0-RTT early data for certain resumed connections. A client that has previously established a TLS session can use a previously obtained resumption mechanism to send application data earlier in the connection process.

TLS Session Resumption

A complete TLS handshake involves cryptographic operations and network round trips. Session resumption allows a client and server that have communicated previously to establish a new connection more efficiently.

TLS 1.3 uses PSK-based resumption and NewSessionTicket messages. The client can later present the resumption information to establish a connection without repeating the full certificate-based authentication process in the same way as a completely new connection.

What Are Session Keys?

Session keys are symmetric cryptographic keys derived during the TLS handshake. They are used to protect TLS records containing application data.

The handshake therefore has an important architectural role: it establishes the cryptographic context, while the resulting symmetric keys provide efficient protection for the potentially large amount of data exchanged afterward.

Authenticated Encryption

Modern TLS uses authenticated encryption with associated data, commonly called AEAD. Algorithms such as AES-GCM and ChaCha20-Poly1305 provide confidentiality and integrity protection together.

Why TLS Uses Symmetric Encryption for Application Data

Symmetric encryption is substantially more efficient for bulk data than public-key operations. Once the handshake has established shared traffic keys, TLS can encrypt and authenticate application records efficiently.

This is why the handshake should not be understood as encrypting an entire HTTP session with the server's public key. Public-key cryptography primarily helps establish trust and shared secrets; symmetric cryptography handles the ongoing data transfer.

What Happens After the Handshake?

After the necessary handshake steps complete successfully, the client can send application data through the protected TLS connection. For HTTPS, that application data contains HTTP requests and responses.

HTTPS request
GET /account HTTP/1.1
Host: example.com

The HTTP content is protected by TLS records while it travels between the client and server. An observer on the network can still see certain connection metadata, such as the destination IP address and traffic timing, although TLS protects the application payload.

Does TLS Hide the Domain Name?

Traditional TLS deployments have historically exposed the hostname through SNI during the handshake. Encrypted ClientHello, or ECH, is a newer mechanism designed to encrypt sensitive ClientHello information, including the inner SNI in supported deployments.

ECH support depends on the client, server, DNS configuration, and surrounding infrastructure. It should not be confused with ordinary TLS encryption of application data.

Common TLS Handshake Errors

A TLS handshake can fail before any HTTP request reaches the application. The error may be caused by protocol incompatibility, certificate problems, unsupported algorithms, incorrect hostname configuration, or network infrastructure.

Certificate Expiration Problems

A certificate has a defined validity period. If the current time is outside that period, clients can reject the certificate even when the certificate chain and hostname are otherwise correct.

Certificate expiration is one reason automated certificate management and monitoring are important for production HTTPS services.

Hostname Mismatch

A certificate can be perfectly valid and correctly signed but still fail validation if it does not cover the hostname requested by the client.

Requested:
api.example.com

Certificate SAN:
www.example.com

The certificate must contain an appropriate identity for the requested hostname, usually through the Subject Alternative Name extension.

Missing Intermediate Certificates

One of the common server configuration mistakes is providing the leaf certificate without the intermediate certificates required to build a trusted chain.

Different clients can sometimes appear to behave differently because their trust stores and certificate-building behavior vary. A server should therefore provide the certificate chain expected by its clients rather than relying on every client to discover missing intermediates automatically.

TLS Version Mismatch

A handshake can fail when a client and server have no mutually supported TLS version. Modern services generally prefer TLS 1.3 and TLS 1.2 while disabling obsolete protocol versions such as TLS 1.0 and TLS 1.1.

Cipher Suite Mismatch

A client and server must have compatible cryptographic capabilities. If the server supports only algorithms the client cannot use, or if configuration policies eliminate every common option, the handshake can fail.

TLS 1.3 reduces this problem by defining a smaller and more modern set of cipher suites, while key exchange and authentication are negotiated separately.

TLS Handshake and Reverse Proxies

In modern web architectures, TLS may terminate at a reverse proxy, CDN, load balancer, or edge service rather than directly at the application server.

This means the TLS certificate seen by a browser may belong to the edge infrastructure. A separate connection can then exist between that infrastructure and the origin server. When troubleshooting TLS, identify where the TLS connection terminates before investigating the wrong server.

TLS Handshake and Mutual TLS

In ordinary HTTPS, the server authenticates itself to the client. Mutual TLS, or mTLS, adds client authentication using a client certificate.

In an mTLS configuration, the server requests a client certificate and validates it against an appropriate trust configuration. This is common in some service-to-service, enterprise, and API environments.

How to Inspect a TLS Certificate

When investigating a handshake problem, inspect the certificate's subject alternative names, issuer, validity dates, public key, signature algorithm, and chain.

A PEM Certificate Viewer can decode a PEM-formatted certificate and expose its fields in a readable form. A Certificate Chain Viewer can help determine whether the leaf and intermediate certificates form the expected chain.

How a CSR Relates to TLS Certificates

A Certificate Signing Request, or CSR, is created when requesting a certificate from a certificate authority. It contains a public key and identity information and is signed using the corresponding private key.

The CSR is part of certificate issuance rather than the live TLS handshake itself. Once the certificate is issued and installed on the server, the certificate becomes part of the server's TLS authentication process.

Common TLS Configuration Mistakes

• Allowing obsolete TLS protocol versions.
• Using an incomplete certificate chain.
• Installing a certificate for the wrong hostname.
• Letting certificates expire.
• Misconfiguring SNI on a multi-domain server.
• Using incompatible TLS settings across a reverse proxy and origin.
• Assuming certificate validity alone proves that the complete TLS configuration is correct.
• Using legacy cryptographic algorithms when modern alternatives are available.
• Failing to monitor certificate expiration.
• Ignoring handshake failures until users report them.

TLS Handshake Troubleshooting Checklist

• Confirm the requested hostname.
• Check which TLS versions the server supports.
• Inspect the server certificate.
• Verify the certificate validity period.
• Check the Subject Alternative Name entries.
• Inspect the complete certificate chain.
• Verify that the client trusts the issuing chain.
• Check supported cipher suites and key-exchange groups.
• Confirm SNI configuration for multi-domain servers.
• Determine where TLS terminates in the network.
• Check whether a reverse proxy or CDN changes the observed certificate.
• Inspect server and client TLS logs when available.

How to Think About the TLS Handshake

A useful way to understand the handshake is to separate its responsibilities. First, the client and server need compatible protocol parameters. Second, the server needs to prove its identity. Third, both sides need to establish shared secret material. Finally, they derive symmetric traffic keys and use them to protect application data.

This separation explains why certificates, public-key cryptography, key exchange, digital signatures, and symmetric encryption all appear in the same protocol without performing the same job.

TLS Handshake vs HTTP Request

This distinction is useful when debugging. If the TLS handshake fails, the HTTP request may never reach the application server. If TLS succeeds but the HTTP request returns a 404 or 500 response, the problem is at a later layer.

TLS Handshake Performance

The handshake introduces network round trips and cryptographic work before application data can be exchanged normally. TLS 1.3 reduces the number of round trips required for a full handshake compared with typical TLS 1.2 handshakes.

Session resumption can reduce connection-establishment overhead further. HTTP/2 and HTTP/3 can also reduce the frequency with which new connections are needed by allowing multiple requests or streams to share a connection.

TLS 1.3 and HTTP/3

HTTP/3 uses QUIC as its transport protocol, and QUIC incorporates TLS 1.3 for its cryptographic handshake. This means TLS remains central to connection security even though HTTP/3 does not use traditional TCP-based HTTPS connections.

QUIC integrates transport and TLS handshake behavior differently from TCP-based HTTP/2 connections, but the underlying TLS 1.3 cryptographic mechanisms still provide authentication and key establishment.

Frequently Asked Questions

Helpful TLS Tools

A TLS Version Checker can help inspect supported protocol versions, while a Certificate Chain Viewer is useful for investigating certificate-chain problems. A PEM Certificate Viewer can expose certificate fields such as SAN entries, issuer, validity dates, and public keys. A CSR Generator helps create certificate signing requests, and a Certificate Expiration Checker can be used to monitor certificate validity periods before they cause connection failures.

Conclusion

The TLS handshake is the foundation of a secure HTTPS connection. It allows the client and server to negotiate compatible cryptographic parameters, authenticate the server, establish shared secrets, and derive symmetric keys for protecting application data.

TLS 1.3 modernizes this process by reducing handshake latency, removing legacy mechanisms, requiring ephemeral key exchange, and encrypting more of the handshake after the initial key exchange. TLS 1.2 remains relevant because it is still present in many existing systems and must be configured carefully.

When troubleshooting a TLS failure, inspect the protocol version, certificate validity, hostname, certificate chain, supported cryptographic parameters, SNI, and the location where TLS terminates. Understanding what each handshake component does makes certificate and HTTPS problems much easier to diagnose.