Back to Learning Center
Error Fix

SSL Handshake Failed: All Causes and Fixes

9 min read·Updated June 2026·By CertNotify Team

"SSL handshake failed" is one of the most frustrating errors because it can stem from a dozen different causes. This guide covers every common scenario with specific diagnostics and fixes for each.

What Happens During a TLS Handshake

The handshake is a multi-step negotiation that must succeed before any data is exchanged. If any step fails, the connection is terminated with a handshake failure:

  1. Client Hello: browser sends supported TLS versions and cipher suites.
  2. Server Hello: server picks version and cipher, sends certificate.
  3. Certificate Verification: client validates certificate chain.
  4. Key Exchange: both sides derive session keys.
  5. Finished: encrypted connection established.

Cause 1: Cipher Suite Mismatch

Client and server share no common cipher suites. You will see: handshake_failure (40) or no ciphers available.

# Check server cipher suites
nmap --script ssl-enum-ciphers -p 443 yourdomain.com

# Or with OpenSSL
openssl s_client -connect yourdomain.com:443 -cipher "ECDHE-RSA-AES256-GCM-SHA384"
# Nginx fix — modern cipher configuration
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;

Cause 2: TLS Protocol Version Mismatch

Client requires TLS 1.2+ but server only offers TLS 1.0/1.1 (or vice versa if client is old).

# Test each version
openssl s_client -connect yourdomain.com:443 -tls1_2 2>&1 | grep "Cipher is"
openssl s_client -connect yourdomain.com:443 -tls1_3 2>&1 | grep "Cipher is"

Ensure server supports TLSv1.2 TLSv1.3 minimum. For Nginx: ssl_protocols TLSv1.2 TLSv1.3;

Cause 3: Certificate Validation Failure

certificate has expired

Renew the certificate immediately. Check auto-renewal configuration.

hostname/IP does not match

Certificate CN/SAN does not cover this domain. Reissue with correct domains in the SAN.

certificate not trusted

Self-signed or from unknown CA. Install a certificate from a trusted CA, or add CA to client trust store for internal use.

incomplete chain

Add intermediate certificates to the ssl_certificate file (fullchain.pem).

Cause 4: SNI (Server Name Indication) Issues

SNI allows multiple certificates on one IP. If the client does not send SNI, the server may present the wrong certificate.

# With SNI (correct)
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

# Without SNI (may get wrong cert)
openssl s_client -connect 203.0.113.1:443 -noservername

Old clients (Java 6, Android 2.x, IE 6 on XP) do not support SNI. If you must support them, use a dedicated IP per certificate or a unified certificate (multi-domain).

Cause 5: Firewall or Middlebox Interference

DPI (Deep Packet Inspection) firewalls, IDS/IPS, and enterprise proxies can corrupt or terminate TLS handshakes. Symptoms: works on some networks, fails on others; works without VPN, fails with VPN.

Test from different networks (mobile hotspot vs corporate WiFi)
Test with and without VPN
Check if antivirus SSL inspection is intercepting connections
Try setting MTU to 1400 bytes for networks with problematic fragmentation

Cause 6: Client Certificate (mTLS) Issues

For mutual TLS (mTLS) setups, the server requires a client certificate. Error: certificate required. Ensure your API client is configured with the correct client certificate and private key. Check that the client cert was signed by the CA your server trusts for client auth.

# Enable verbose TLS logging for debugging
SSLKEYLOGFILE=/tmp/ssl.log curl -v https://yourdomain.com

# Java: add system property
-Djavax.net.debug=ssl:handshake:verbose

Use our free SSL Certificate Checker and TLS Checker to diagnose certificate and protocol issues on any domain without installing any tools.

Common questions

What causes an SSL handshake failure?

The most common causes are: an expired or invalid SSL certificate, a TLS version mismatch between client and server (e.g. the server only supports TLS 1.0 but the client requires 1.2+), a cipher suite mismatch, an incorrect or missing SNI header, firewall rules blocking TLS negotiation, or a misconfigured certificate chain missing intermediate certificates.

How do I fix SSL_ERROR_HANDSHAKE_FAILURE_ALERT?

First check the certificate is valid and not expired. Then verify TLS version support — enable TLS 1.2 and 1.3 on the server and disable TLS 1.0/1.1. Check that the cipher suites supported by both client and server have at least one match. Finally, confirm the server is sending the complete certificate chain including intermediate certificates.

What is SNI and why does it cause handshake failures?

Server Name Indication (SNI) is a TLS extension that tells the server which hostname the client is connecting to, enabling multiple SSL certificates on one IP address. If the client does not send an SNI header, or sends the wrong hostname, the server may present the wrong certificate or reject the connection — causing a handshake failure.

Can a firewall cause SSL handshake failures?

Yes. Deep Packet Inspection (DPI) firewalls and some proxies intercept TLS connections and re-encrypt traffic with their own certificate. If the certificate they present is not trusted by the client, or if they do not support modern TLS versions or cipher suites, the handshake will fail. This is common in corporate networks and some ISPs.

References and further reading

The specifications and primary documentation this article is based on.

Read next

More guides on the same subject.

Keep Your SSL Healthy

Most SSL handshake failures stem from expired certificates or configuration drift. CertNotify checks your certificates once a day and emails you before one expires, so the most common cause is caught before it reaches users.

Go to Dashboard