SSL & HTTPS Guides

Troubleshooting SSL Handshake Failures

Learn why SSL/TLS handshakes fail, how to diagnose protocol, cipher, SNI, certificate chain and CDN/origin issues, and how to fix them.

By CheckDomainHealth Editorial Team Reviewed by Dionis Ceban Updated Jun 28, 2026 9 min read Beginner

Introduction

An SSL/TLS handshake failure means the client and server could not establish a secure HTTPS connection. The browser, API client, CDN or server tried to negotiate TLS, but the negotiation failed before normal page content could load.

Handshake failures can be caused by old TLS versions, unsupported cipher suites, missing SNI, invalid certificate chains, client certificate requirements, CDN/origin SSL mismatch, firewall interference or server misconfiguration. The fix depends on where the handshake fails and which side cannot agree.

Quick answer

Quick answer

SSL handshake failures happen when the client and server cannot agree on a secure TLS connection. Check supported TLS versions, cipher suites, SNI, certificate chain, hostname coverage, CDN/origin SSL settings and server logs. Test the public hostname and the origin separately if a CDN is used.

SSL handshake failure

The SSL/TLS handshake is the negotiation that happens before secure HTTPS traffic begins.

  1. The client connects to the server.
  2. Supported TLS versions are negotiated.
  3. Cipher suites are selected.
  4. The server presents a certificate.
  5. The client verifies trust and hostname.
  6. Encryption keys are established.
  7. Secure communication begins.

If this process fails, the page or API request may stop before any normal HTTP response is returned.

Error messages

Browser errors

ERR_SSL_PROTOCOL_ERROR, ERR_SSL_VERSION_OR_CIPHER_MISMATCH, PR_END_OF_FILE_ERROR, SSL_ERROR_HANDSHAKE_FAILURE_ALERT, NET::ERR_CERT_INVALID

Command-line / API errors

handshake failure, TLS alert handshake failure, certificate verify failed, unable to get local issuer certificate, wrong version number, no shared cipher

CDN errors

SSL handshake failed, origin SSL error, Cloudflare 525, Cloudflare 526, TLS negotiation failed

Different tools use different wording, but the root issue is usually TLS negotiation, certificate validation or CDN/origin configuration.

Where it fails

Before fixing the issue, identify where the handshake fails.

  • Browser to website
  • Browser to CDN edge
  • CDN to origin server
  • API client to server
  • Load balancer to backend
  • Reverse proxy to application
  • Mail or web service using TLS internally

If a CDN is active, visitors may connect successfully to the CDN while the CDN fails to connect securely to the origin server.

TLS version mismatch

A TLS version mismatch happens when the client and server do not support a common protocol version.

  • Server only supports old TLS versions
  • Client requires TLS 1.2 or TLS 1.3
  • Server disables TLS 1.2 accidentally
  • Old client cannot support modern TLS
  • CDN edge and origin use different TLS requirements
Recommended public website setup 
Enable:
TLS 1.2
TLS 1.3

Disable:
SSLv2
SSLv3
TLS 1.0
TLS 1.1

If you disable old protocols, test business-critical legacy clients before applying changes widely.

Cipher mismatch

Cipher suites define which cryptographic algorithms the client and server can use. If there is no shared cipher suite, the handshake can fail.

  • Server allows only outdated ciphers
  • Client rejects weak ciphers
  • Server configuration is too restrictive
  • Old Java, OpenSSL or embedded client cannot negotiate
  • CDN or load balancer has a different cipher profile

For most websites, using a modern recommended TLS profile from the hosting provider, CDN or server stack is safer than manually inventing cipher settings.

SNI problems

SNI, or Server Name Indication, lets the client tell the server which hostname it wants during the TLS handshake. This is important when multiple HTTPS sites share the same IP address.

  • Old clients do not send SNI
  • Server virtual host is misconfigured
  • Wrong default certificate is served
  • CDN or proxy sends the wrong SNI to origin
  • Origin certificate does not match the SNI hostname

If the wrong certificate appears only for some clients, SNI may be involved.

Why this matters

Why this matters

Handshake failures matter because the secure connection fails before the website can load normally. Users may see browser errors, APIs may fail, CDNs may return origin SSL errors and monitoring tools may report downtime even when the web server itself is running.

A handshake failure is often more severe than a normal HTTP error because the client may never receive a useful HTTP response.

How to diagnose

Use SSL Checker, Website Status Checker and command-line tests to identify whether the issue is certificate, protocol, cipher, SNI, CDN or origin related.

When checking handshake failures, review

These seven checks help narrow down the cause.

Public hostname

Test the exact domain visitors use.

Certificate status

Check expiry, hostname match, issuer and chain.

TLS versions

Confirm supported TLS versions.

Cipher suites

Check whether modern clients have shared ciphers.

SNI behavior

Test with the correct server name.

CDN vs origin

Test both public CDN hostname and origin if applicable.

Server logs

Review Nginx, Apache, LiteSpeed, CDN, proxy or application logs.

Check public TLS handshake 
openssl s_client -connect example.com:443 -servername example.com
Check certificate chain 
openssl s_client -connect example.com:443 -servername example.com -showcerts
Test TLS 1.2 
openssl s_client -connect example.com:443 -servername example.com -tls1_2
Test TLS 1.3 
openssl s_client -connect example.com:443 -servername example.com -tls1_3
Check HTTPS response 
curl -Iv https://example.com
Check with specific hostname/SNI 
openssl s_client -connect 192.0.2.10:443 -servername example.com

These examples are illustrative. Replace example.com and IP addresses with your real hostname and server values.

Check SSL handshake

Use SSL Checker to inspect certificate, TLS version support, chain and HTTPS configuration.

Run SSL Check →

Common problems

No shared TLS version

High

Client and server cannot agree on a TLS protocol version.

Next step: Enable TLS 1.2 and TLS 1.3 where possible, and remove obsolete protocol dependencies.

No shared cipher

High

Client and server do not support a common cipher suite.

Next step: Use a modern server or CDN TLS profile and avoid overly restrictive cipher settings.

Wrong certificate served

High

The server presents a certificate for another hostname.

Next step: Check SNI, virtual host configuration, CDN origin settings and certificate coverage.

Incomplete certificate chain

Medium

The client cannot build a trusted certificate chain.

Next step: Install the full certificate chain or CA bundle.

Origin certificate rejected by CDN

High

The CDN connects to the origin but rejects the origin certificate.

Next step: Install a valid origin certificate or adjust CDN SSL mode correctly.

Client too old

Medium

An old browser, Java client, OpenSSL library or embedded device cannot negotiate modern TLS.

Next step: Update the client or maintain a separate compatibility strategy if required.

Mutual TLS required unexpectedly

Medium

The server expects a client certificate, but the client does not provide one.

Next step: Review mTLS configuration and disable client certificate requirement if unintended.

Firewall or proxy interference

Medium

A firewall, WAF, proxy or middlebox interrupts TLS negotiation.

Next step: Check security rules, proxy configuration and TLS inspection settings.

Server name / SNI mismatch

High

The client or CDN sends one hostname, but the origin expects another.

Next step: Align SNI, origin hostname and certificate SAN names.

How to fix failures

  1. Step 1: Identify the failing path

    Determine whether the failure is browser to site, CDN to origin, API client to server, or proxy to backend.

  2. Step 2: Test the public hostname

    Use SSL Checker and browser tests for the exact hostname users access.

  3. Step 3: Check certificate and chain

    Fix expiry, hostname mismatch, trust and incomplete chain issues.

  4. Step 4: Check TLS versions

    Enable TLS 1.2 and TLS 1.3 where supported. Disable obsolete protocols carefully.

  5. Step 5: Check cipher suites

    Use a modern recommended TLS profile.

  6. Step 6: Check SNI

    Confirm the client, CDN or proxy sends the hostname covered by the certificate.

  7. Step 7: Check CDN/origin SSL

    Verify edge certificate, origin certificate, SSL mode and origin hostname.

  8. Step 8: Review logs

    Look for TLS alerts, certificate errors, protocol mismatch or handshake failure messages.

  9. Step 9: Re-test from outside

    Confirm the fix from an external network, not only from the server itself.

Use this checklist to confirm all handshake-related settings are correct.

  • Exact hostname tested
  • DNS points to expected endpoint
  • Certificate covers hostname
  • Certificate chain is complete
  • Certificate is not expired
  • TLS 1.2 is enabled
  • TLS 1.3 is enabled if supported
  • Obsolete protocols are not required
  • Cipher profile is modern
  • SNI is correct
  • CDN edge certificate is valid
  • Origin certificate is valid
  • Firewall, WAF or proxy is not interrupting TLS
  • Server logs show no TLS alerts

CDN and origin

When a CDN is used, there are usually two TLS handshakes.

Browser to CDN

  • The visitor checks the CDN edge certificate.

CDN to origin

  • The CDN checks the origin server certificate.
  • Origin certificate is expired
  • Origin certificate does not match hostname
  • CDN sends wrong SNI
  • Origin supports old TLS only
  • CDN requires strict certificate validation
  • Origin firewall blocks CDN IPs
  • Redirect rules conflict with SSL mode

If users see a CDN SSL error, test the CDN edge and origin separately.

API compatibility

Handshake failures are common with API clients and older libraries.

  • OpenSSL version
  • Java version
  • cURL or libcurl version
  • Node, Python or PHP TLS support
  • Trusted CA bundle
  • SNI support
  • Proxy settings
  • Client certificate requirement
  • TLS version policy

A website may work in modern browsers but fail in an old application client.

Frequently asked questions

What is an SSL handshake failure?

It means the client and server could not establish a secure TLS connection.

Is a handshake failure always a certificate problem?

No. It can also be caused by TLS version mismatch, cipher mismatch, SNI issues, CDN/origin problems or client compatibility.

What does no shared cipher mean?

The client and server do not support a common cipher suite for the TLS connection.

Can a CDN cause handshake failures?

Yes. A CDN can fail the handshake with the origin if the origin certificate, SNI, TLS version or SSL mode is wrong.

Why does the site work in a browser but fail in an API client?

The API client may use an old TLS library, outdated CA bundle, missing SNI support or restricted cipher settings.

Does enabling TLS 1.2 fix handshake errors?

It can fix some issues, but you still need to check certificate chain, ciphers, SNI and CDN/origin settings.

How do I confirm the fix worked?

Run SSL Checker and external command-line tests against the exact public hostname and any relevant origin endpoint.

Use these free tools to verify your configuration after applying changes.

SSL Checker Website Status Checker HTTP Header Checker DNS Lookup Domain Health Checker
Understanding TLS Versions and Why SSLv3 Is Insecure 8 min read Using a CDN with HTTPS 8 min read Understanding Certificate Authorities and Trust Chains 8 min read Fixing Domain Mismatch Errors in SSL Certificates 8 min read How to Check Your SSL Certificate 8 min read
Browse all SSL & HTTPS guides →

Need help applying this fix?

Send us your domain, report link or issue details. CheckDomainHealth will review the request and route it to the right technical team if hands-on support is needed.

Get Help Run Domain Health Check

Was this guide helpful?

Your feedback helps us improve our guides for everyone.