TLS Handshake: Understand Every Step and Fix Common Errors
A TLS handshake is the security negotiation that takes place before a browser, application or device exchanges protected information with a server. During this process, both sides agree on security settings, authenticate the server and generate shared encryption keys. Once the handshake succeeds, information can travel through an encrypted connection instead of being exposed as readable data.
You experience this process whenever you open an HTTPS website, sign in to an online account, use a secure application or connect to many protected APIs. The handshake normally finishes so quickly that users never notice it. However, expired certificates, unsupported protocol versions, incorrect server settings and network interference can prevent the secure connection from being established.
TLS protects communication against eavesdropping, tampering and message forgery. The handshake does not encrypt all internet activity by itself; instead, it establishes the keys and security parameters used by the TLS record layer. The current TLS 1.3 specification is published as RFC 9846, while TLS 1.2 remains available for compatible existing systems.
This guide explains what a TLS handshake is, how its messages work and how TLS 1.3 differs from TLS 1.2. It also covers certificates, cipher suites, mutual TLS, session resumption, common TLS handshake errors and practical troubleshooting methods. The explanations use simple language while preserving the technical details needed by developers, administrators and website owners.
What Is a TLS Handshake?
A TLS handshake is a structured exchange of messages between a client and a server. A web browser usually acts as the client, while the website’s hosting system acts as the server. The process allows both endpoints to agree on a supported protocol version, choose cryptographic algorithms and establish the secrets needed for protected communication.
The handshake also helps the client confirm that it is communicating with the intended server. The server normally sends a digital certificate containing its identity and public key information. The client validates that certificate against trusted certificate authorities, checks the hostname and confirms that the certificate is currently valid before accepting the connection.
TLS describes its handshake as an authenticated key exchange. When it succeeds, both endpoints should derive matching session keys, agree on cryptographic parameters and establish the authenticated identities involved in the connection. These results allow later application data to be encrypted and checked for unauthorised modification.
The term SSL handshake is still commonly used, but modern secure connections use TLS rather than the obsolete SSL protocols. People may say SSL certificate, SSL error or SSL/TLS handshake when referring to the same general website-security process. Technically, TLS is the current protocol family, while older SSL versions should not be enabled.
Why the TLS Handshake Matters
The handshake provides confidentiality by establishing encryption keys before sensitive information is exchanged. Without encryption, someone monitoring the network might read passwords, payment details, messages or API data. TLS transforms application traffic into protected records that should be unintelligible to observers who do not possess the correct session keys.
It also provides integrity protection. Each protected record includes cryptographic authentication that allows the receiving endpoint to detect unauthorised modification. If an attacker changes information while it is travelling across the network, the verification should fail rather than silently delivering altered data to the browser, application or server.
Authentication is another essential purpose. In a typical HTTPS connection, the server proves its identity by presenting a certificate and signing parts of the handshake. This helps prevent an attacker from impersonating a legitimate website. Mutual TLS can extend authentication in the opposite direction by also requiring the client to provide a certificate.
A successful handshake therefore answers three practical questions: which security settings will be used, whether the expected endpoint can be trusted and which secret keys will protect the session. TLS 1.2 was specifically designed to prevent eavesdropping, tampering and message forgery, while TLS 1.3 simplified and strengthened the negotiation.
How the TLS Handshake Starts
Before the TLS negotiation can begin over traditional HTTPS, the client normally establishes a TCP connection with the server. The browser resolves the domain name, connects to the server’s IP address and opens the relevant port, usually port 443 for HTTPS. The TLS messages are then exchanged through that underlying network connection.
The first major TLS message is called ClientHello. It tells the server which TLS versions, cryptographic groups, signature algorithms and other capabilities the client supports. It also contains random data used during key derivation and may include the requested server name so a hosting platform can select the correct certificate.
The ClientHello can contain Application-Layer Protocol Negotiation information, commonly called ALPN. This extension allows the client to advertise application protocols such as HTTP/2. The same message may contain session-resumption information, supported key shares and other extensions needed to negotiate a modern connection efficiently.
Some ClientHello details have traditionally been visible to network observers. Encrypted Client Hello, standardised in RFC 9849, can protect sensitive fields such as the requested server name and ALPN list when supported and correctly deployed. ECH improves handshake privacy, although IP addresses and unencrypted DNS activity may still reveal information.
ClientHello and ServerHello
After receiving the ClientHello, the server compares the client’s capabilities with its own configuration. It selects a mutually supported TLS version, cipher suite and key-exchange group. When no acceptable combination exists, the server cannot continue normally and may send an alert indicating that the TLS handshake has failed.
The server responds with a ServerHello containing its selected parameters and key-share information. In TLS 1.3, this response enables both endpoints to calculate shared handshake secrets. The server does not simply send the final encryption key across the internet; both sides independently derive matching keys from cryptographic inputs exchanged during the negotiation.
The server may request another ClientHello when the first message does not include a suitable key share. This response is called HelloRetryRequest and tells the client which supported group to use. The additional exchange increases latency, so well-configured clients usually offer an appropriate key share during the initial attempt.
Version negotiation is important because the client and server may support different protocol generations. The server is generally expected to choose the highest version supported by both sides. Current IETF guidance requires new protocols using TLS to make TLS 1.3 the default, while TLS 1.2 may remain an additional compatibility option.
TLS Certificate Verification
The server certificate connects the website’s domain identity with a cryptographic public key. It normally forms part of a certificate chain beginning with the website certificate, continuing through one or more intermediate certificate authorities and ending at a root authority trusted by the client’s operating system or application.
The client checks whether the certificate was issued by a trusted authority and whether its digital signatures are valid. It also confirms that the certificate covers the requested hostname. A certificate issued for another domain should not be accepted merely because its dates and signature chain are otherwise valid.
Validity dates are checked to ensure that the certificate is not being used before its activation date or after its expiration. Incorrect system time can therefore create certificate errors even when the server is properly configured. Clients may also use revocation mechanisms to determine whether an authority has invalidated a certificate before its normal expiration.
An incomplete certificate chain is a common configuration problem. A server may send its own certificate but omit the required intermediate certificate, leaving some clients unable to construct a trusted path. Administrators should install the full chain required by their certificate authority and test it from multiple clients rather than assuming one successful browser test proves universal compatibility.
Key Exchange and Session Keys
Key exchange allows the client and server to establish shared secrets without transmitting the final session keys directly. Modern TLS 1.3 commonly uses ephemeral Diffie–Hellman techniques based on supported finite-field or elliptic-curve groups. Each endpoint contributes temporary key material and independently calculates the same shared secret.
Those shared inputs are processed through a key-derivation system to create several secrets for different stages of the connection. Handshake traffic keys protect later handshake messages, while application traffic keys protect information sent after authentication finishes. Separate keys are used for client-to-server and server-to-client communication.
Ephemeral key exchange supports forward secrecy. If an attacker records encrypted traffic and later obtains the server’s certificate private key, that key alone should not reveal the temporary secrets created for earlier sessions. This provides stronger protection than older static RSA key-exchange methods that depended directly on the server’s long-term private key.
TLS 1.2 supported many key-exchange choices, some of which are now considered unsuitable. RFC 10015, published in July 2026, deprecates obsolete TLS 1.2 methods, including static RSA and several non-ephemeral Diffie–Hellman options. Modern deployments should prefer TLS 1.3 and carefully restrict any TLS 1.2 fallback configuration.
Server Authentication Messages
After establishing preliminary handshake keys, the TLS 1.3 server sends encrypted negotiation and authentication messages. These typically include EncryptedExtensions, the server’s Certificate message, CertificateVerify and Finished. Encrypting most of this part of the handshake improves privacy compared with TLS 1.2, where more handshake information remained visible.
The Certificate message provides the certificate chain needed by the client. CertificateVerify contains a digital signature created with the private key corresponding to the server certificate. This signature demonstrates that the server controls the relevant private key and connects its identity to the current handshake rather than to an unrelated session.
The Finished message is calculated from the handshake secrets and a transcript of the messages exchanged so far. The client verifies it to confirm that both endpoints observed the same negotiation and derived compatible secrets. An altered message, incorrect key or broken implementation should cause this verification to fail.
After validating the server, the client sends its own Finished message. Both sides can then use their application traffic keys to protect website requests, API calls or other application information. If mutual TLS is enabled, the client also sends certificate and signature messages so the server can authenticate the client before accepting the connection.
TLS 1.2 Handshake Process
A traditional TLS 1.2 handshake begins with ClientHello and ServerHello messages. The server then sends its certificate and, depending on the selected cipher suite, additional key-exchange information. It may request a client certificate before signalling that its first group of handshake messages has finished.
The client validates the certificate and sends its key-exchange message. When client authentication is requested, it may also send its certificate and a signature proving possession of the matching private key. Both endpoints calculate the master secret and derive encryption and authentication keys from that secret and the negotiated parameters.
TLS 1.2 then uses ChangeCipherSpec and Finished messages to activate the negotiated protection. The client and server each confirm that the handshake transcript is valid. A full TLS handshake in versions through TLS 1.2 traditionally requires two protocol round trips before application information can begin flowing normally.
TLS 1.2 can still be configured securely, but doing so requires careful cipher-suite, extension and key-exchange choices. Current IETF guidance describes TLS 1.2 as more difficult to secure than TLS 1.3, and the TLS working group has placed it in feature freeze. New protocols are now expected to use TLS 1.3 as their default.
TLS 1.3 Handshake Process
TLS 1.3 reduces the number of messages and removes several outdated options. The client normally includes a key share in its first ClientHello. The server responds with its selected version, cipher suite and key share, allowing both endpoints to derive handshake keys after one round trip rather than waiting for additional key-exchange messages.
The server then sends encrypted configuration and authentication information, including its certificate, signature and Finished message. The client validates those messages and returns its own Finished response. Application data can begin after this shorter negotiation, reducing connection delay compared with a full TLS 1.2 handshake.
TLS 1.3 also separates cipher suites from authentication and key-exchange choices. Its cipher suites primarily specify the authenticated-encryption algorithm and hash function. This cleaner design avoids the large number of combined cipher-suite options supported by earlier TLS versions and reduces opportunities for unsafe algorithm combinations.
The current TLS 1.3 specification is RFC 9846, published in July 2026. IETF guidance now requires new protocols using TLS to support TLS 1.3 as the default. TLS 1.2 may be retained when deployment compatibility demands it, but new designs should not depend on older protocol versions.
TLS 1.2 vs TLS 1.3
The most visible difference is handshake speed. A full TLS 1.2 connection generally requires two network round trips before normal application traffic, while TLS 1.3 can usually complete its full handshake in one round trip. This improvement is especially valuable on mobile networks and long-distance connections where latency is noticeable.
TLS 1.3 also removes legacy algorithms and protocol features that complicated secure configuration. Static RSA key exchange, older CBC-based choices and several weak or obsolete combinations are absent from its normal design. TLS 1.2 included a much broader collection of options, requiring administrators to disable unsafe choices manually.
Privacy is improved because TLS 1.3 encrypts most handshake messages after ServerHello, including the server certificate. TLS 1.2 exposes more negotiation information before encryption begins. Encrypted Client Hello can further protect the initial ClientHello’s requested server name and other sensitive extensions when both sides support it.
TLS 1.2 is not automatically insecure, but it has entered feature freeze and requires tighter configuration. TLS 1.0 and TLS 1.1 have been formally deprecated because they lack modern cryptographic mechanisms and increase the risk of weak configuration. Administrators should disable those older versions and prioritise TLS 1.3.
Session Resumption
A full handshake performs certificate validation, authentication and key establishment, which consumes time and computing resources. Session resumption allows a returning client to establish a new protected connection using information from an earlier session. This reduces repeated work while generating fresh traffic keys for the new connection.
In TLS 1.3, the server can send NewSessionTicket messages after the initial handshake. The client stores the ticket and associated secret securely. During a later connection, it presents a pre-shared-key identity derived from that session, allowing the server to resume the relationship without repeating the complete certificate-based authentication flow.
A resumed TLS 1.3 connection can complete with a one-round-trip exchange and may support 0-RTT early data. With 0-RTT, the client sends certain application information immediately with its first flight. This improves speed, but the data does not receive the same replay protection as ordinary application traffic.
Applications should only use 0-RTT for operations that remain safe when replayed. A simple read request may be acceptable, while a payment, purchase or account-changing action could be dangerous if processed more than once. Server and application developers must evaluate replay risk rather than enabling early data purely for performance.
Mutual TLS Handshake
Most public HTTPS connections authenticate only the server. The browser confirms the website’s identity, but the user normally proves identity later with a password, cookie or security token. Mutual TLS, often shortened to mTLS, adds certificate-based client authentication to the handshake itself.
The server sends a CertificateRequest message asking the client to provide an acceptable certificate. The client responds with its certificate chain, a CertificateVerify signature and its Finished message. The server validates the client certificate and confirms that the connecting party controls the matching private key.
Mutual TLS is commonly used for service-to-service communication, private APIs, enterprise systems and environments requiring strong device identity. It can reduce reliance on shared passwords, but it introduces certificate issuance, renewal, revocation and storage responsibilities across every authorised client.
A mutual TLS handshake can fail when the client has no suitable certificate, presents an expired certificate or uses a chain the server does not trust. Failures also occur when the private key is missing, permissions prevent access to it or the server accepts different certificate authorities or signature algorithms.
Common TLS Handshake Errors
A certificate error is one of the most frequent causes of a failed TLS handshake. The certificate may be expired, issued for the wrong hostname, signed by an untrusted authority or missing part of its chain. The client rejects the connection because it cannot confidently authenticate the server’s identity.
Protocol mismatch occurs when the endpoints do not share a supported TLS version. A modern client may require TLS 1.2 or TLS 1.3 while a legacy server only supports deprecated versions. The reverse can also happen when an old application cannot understand the server’s modern protocol or certificate configuration.
Cipher-suite and signature-algorithm mismatches cause similar failures. The client offers one set of algorithms, while the server permits another set with no overlap. Older systems may also fail when they cannot process modern elliptic-curve certificates, stronger signature algorithms or larger handshake messages.
Network devices can interrupt the process as well. Firewalls, proxies, antivirus products and TLS-inspection gateways may block a version, alter the ClientHello or present a replacement certificate. Incorrect server-name information can send the connection to the wrong virtual host, producing an unexpected certificate or immediate handshake alert.
How to Fix a TLS Handshake Failed Error
Begin by checking the affected device’s date, time and time zone. Certificate verification depends on accurate time, so a badly configured clock can make a valid certificate appear expired or not yet active. Update the browser, operating system and application before investigating more complicated server-side causes.
Website administrators should confirm the certificate’s hostname, validity period and complete chain. Verify that the private key matches the installed certificate and that the service actually loaded the latest files after renewal. Restarting or reloading the web server may be necessary after replacing certificates or changing the TLS configuration.
Check whether the client and server support at least one common protocol version, cipher configuration, signature algorithm and cryptographic group. Disable TLS 1.0 and TLS 1.1 rather than reactivating them as a quick compatibility fix. Current standards formally deprecate those versions, and new protocols must default to TLS 1.3.
When the direct connection works but the normal route fails, inspect load balancers, reverse proxies, content delivery networks and security appliances. TLS may terminate at more than one point, and each connection can have a separate certificate and protocol policy. A correct public certificate does not prove that the proxy-to-origin handshake is configured correctly.
How to Test a TLS Handshake
OpenSSL provides the s_client command for connecting to an SSL or TLS service and examining its behaviour. The official OpenSSL documentation describes it as a general TLS client and a useful diagnostic tool for SSL servers. It can display certificates, negotiated versions, cipher information and verification results.
A basic HTTPS test uses openssl s_client -connect example.com:443 -servername example.com. The -servername value sends Server Name Indication, which is important when several domains share one IP address. Without it, the server may return a default certificate that does not match the hostname being tested.
Administrators can add -showcerts to display the certificates sent by the server or -verify_return_error to stop when certificate verification fails. Options such as -tls1_2 and -tls1_3 can test individual protocol versions, while -state, -msg and -trace provide progressively deeper handshake details.
Testing should be performed from more than one network and client type. A server may succeed locally while failing through a firewall, proxy or different certificate store. Combine command-line output with browser developer tools, application logs and server logs to identify the exact stage where the negotiation stops.
How to Improve TLS Performance
Enable TLS 1.3 whenever supported because its full handshake generally needs fewer round trips than TLS 1.2. The latency improvement becomes more noticeable when users are geographically distant from the server. Avoid unnecessary redirects because each move to another hostname may require additional DNS, TCP and TLS work.
Use session resumption so returning clients do not repeat every step of the complete certificate-based handshake. Configure ticket lifetimes and key rotation carefully, balancing performance with security. Monitor whether resumption is actually occurring instead of assuming that enabling a configuration option guarantees clients can use it successfully.
Keep the certificate chain as short as reasonably possible while still providing the required intermediate certificates. Large certificate chains increase the amount of handshake data transmitted. Certificate choices, key sizes and unnecessary extensions can also affect processing and network overhead, especially for constrained devices or high-traffic services.
Reduce avoidable HelloRetryRequest responses by supporting commonly used cryptographic groups and maintaining compatible server settings. A retry adds another exchange before the handshake can continue. Performance testing should measure real connection establishment from different networks instead of focusing only on the server’s application response time.
TLS Handshake Security Practices
Support TLS 1.3 and maintain TLS 1.2 only where existing clients require it. New protocols using TLS must default to TLS 1.3 under the IETF’s July 2026 guidance. Older TLS 1.0 and TLS 1.1 versions are deprecated and should remain disabled rather than being treated as convenient fallback options.
For TLS 1.2 compatibility, remove obsolete key-exchange methods and weak cipher suites. RFC 10015 deprecates static RSA key exchange and several older Diffie–Hellman methods in TLS 1.2. Current best practice also rejects RC4 and discourages vulnerable CBC configurations where stronger authenticated-encryption choices are available.
Automate certificate renewal and monitor expiration rather than relying on manual calendar reminders. Confirm that renewed certificates are deployed to every load balancer, proxy and regional endpoint. Protect private keys with strict access controls, and rotate them when compromise is suspected instead of merely issuing a certificate with new dates.
Test configuration changes before broad deployment and monitor handshake-failure rates afterward. Record negotiated versions, certificate errors and alerts without logging secret keys or sensitive application information. A secure configuration must remain compatible with the intended clients, but compatibility should not be achieved by restoring protocols or algorithms that standards have deprecated.
FAQs
What happens during a TLS handshake?
The client and server agree on a TLS version and cryptographic settings, authenticate the server and derive shared session keys. They then use those keys to encrypt and verify application data.
How long does a TLS handshake take?
A full TLS 1.3 handshake normally requires one network round trip after the underlying connection is available. A traditional full TLS 1.2 handshake generally requires two round trips.
What causes a TLS handshake failure?
Common causes include expired certificates, incorrect hostnames, incomplete certificate chains, incompatible TLS versions, unsupported algorithms, wrong system time and interference from proxies or firewalls.
Is a TLS handshake the same as an SSL handshake?
The terms are often used interchangeably, but TLS is the modern protocol. SSL versions are obsolete, so current HTTPS connections should use TLS 1.2 or preferably TLS 1.3.
Can a TLS handshake be intercepted?
An observer can see some connection information, but successful certificate verification and cryptographic authentication are designed to prevent undetected impersonation. ECH can also encrypt sensitive ClientHello fields when supported.
TLS Handshake: Final Takeaways
A TLS handshake creates the secure foundation for HTTPS, protected APIs and many other encrypted services. The client and server negotiate compatible settings, authenticate identities and independently derive matching session keys. Only after these checks succeed should sensitive application information move through the protected connection.
TLS 1.3 provides a shorter and cleaner handshake than TLS 1.2. It removes outdated options, encrypts more of the negotiation and normally completes a full connection with fewer network round trips. The IETF now requires new protocols using TLS to make TLS 1.3 their default.
When a handshake fails, begin with certificates, system time and protocol compatibility. Then inspect cipher settings, signature algorithms, server-name information and intermediary network devices. OpenSSL s_client, application logs and server logs can reveal which message or verification step prevented the connection from completing.
A reliable TLS deployment requires more than installing a certificate. Administrators must disable obsolete versions, maintain secure algorithm choices, automate renewals and test every termination point. Understanding the TLS handshake process makes it easier to improve security, reduce connection delays and resolve errors before they affect users.
