How to Fix the SSL Handshake Failed Error?

Published: December 2022. Updated: August 2026. Reviewed by Encryption Consulting’s PKI Advisory team.

The SSL/TLS handshake is the negotiation a client and server run before any encrypted data moves between them: they agree on a protocol version, a cipher suite, exchange or validate certificates, and derive shared session keys. When that negotiation cannot complete, the connection terminates with an “SSL handshake failed” (or “TLS handshake failed”) error instead of opening the secure channel. Technically, SSL (Secure Sockets Layer) was replaced by TLS (Transport Layer Security) years ago; both browsers and this guide use “SSL handshake” as the common name for what is, on any current system, a TLS handshake.

This guide covers why the handshake fails, how to diagnose the specific cause instead of guessing, the fixes for each root cause, which “fixes” quietly remove security, and how to prevent the error through certificate lifecycle management rather than repeated firefighting.

What Causes an SSL Handshake Failure?

An SSL handshake failure happens when the client and server cannot agree on a protocol version, a cipher suite, or cannot validate each other’s identity within the handshake. The TLS specification defines a fatal handshake_failure alert (alert code 40) for exactly this case: “no overlapping cipher suites, TLS versions, signature algorithms, or named groups were found between client and server,” per the TLS alert protocol reference and the base specification in RFC 8446, the TLS 1.3 protocol. In practice, the error message your browser or client shows rarely distinguishes between these causes, which is why diagnosis (next section) matters more than guessing at a fix. The most common root causes are:

• Cipher suite mismatch. The client and server share no common cipher suite, often because a server has been hardened to modern AEAD-only ciphers while an older client (or a middlebox) only offers deprecated ones.
• Protocol version mismatch. A client stuck on TLS 1.0 or TLS 1.1 tries to connect to a server that no longer accepts them. RFC 8996 formally deprecated TLS 1.0 and TLS 1.1 in March 2021, and most modern servers and CDNs now refuse both by default.
• Expired or misconfigured certificate. The server certificate has passed its notAfter date, or its subject/SAN entries do not match the hostname the client requested.
• Incomplete certificate chain. The server sends only its leaf certificate without the required intermediate certificate authority (CA) certificate, so the client cannot build a trust path to a root it already trusts.
• Clock skew. Certificate validity is time-bound. If the client or server system clock is wrong, a certificate that is actually valid can appear expired or not-yet-valid, and the handshake fails on validation.
• SNI (Server Name Indication) issues. On a server hosting multiple TLS certificates behind one IP, Server Name Indication tells the server which hostname the client wants so it can present the matching certificate. If SNI is missing, blocked by a proxy, or misconfigured, the server may present the wrong certificate or refuse the connection, as described in Cloudflare’s explanation of how SNI works.
• Certificate-pinning conflicts. An app or browser extension that pins a specific certificate or public key rejects a legitimately renewed certificate because the pin was never updated, per OWASP’s guidance on certificate and public key pinning.

How Do You Diagnose the Specific Cause of a Handshake Failure?

Diagnose an SSL handshake failure by testing the connection directly with openssl s_client or your browser’s developer tools rather than guessing which fix to try first. Run these steps in order:

1. Test the raw connection with OpenSSL. Run openssl s_client -connect example.com:443 -servername example.com. This forces the correct SNI hostname and shows the negotiated protocol version, cipher suite, and full certificate chain the server actually returned, per the OpenSSL s_client documentation.
2. Check the certificate dates and chain. Add -showcerts to the same command to see every certificate in the chain, and check the “Not Before” / “Not After” fields for expiry. A chain that stops at the leaf certificate with no intermediate means the server is misconfigured, not the client.
3. Force strict verification. Add -CAfile ca-bundle.pem -verify_return_error to make OpenSSL return the exact verification error (expired, self-signed, hostname mismatch, unable to get local issuer certificate) instead of continuing past it.
4. Isolate the protocol version. Re-run the test with -tls1_2 or -tls1_3 appended. If the connection succeeds with one flag and fails with another, the root cause is a protocol version mismatch, not a certificate problem.
5. Isolate the cipher suite. Add -cipher with a specific suite name, or compare against the server’s supported list, to confirm whether the failure is a missing overlapping cipher suite.
6. Check the system clock. Compare the client and server system time against a trusted NTP source. A clock more than a few minutes off can cause certificate validation to fail even when the certificate itself is valid.
7. Cross-check in the browser. Open browser developer tools (Chrome: chrome://net-export or the Security tab in DevTools; Firefox: the Security panel) to see the specific TLS alert the browser received and the certificate it evaluated, which confirms or contradicts the OpenSSL result from a real client.

Which Protocols and Cipher Suites Should You Actually Support?

Support TLS 1.2 and TLS 1.3 only, and restrict cipher suites to AEAD (authenticated encryption with associated data) suites; do not re-enable TLS 1.0 or TLS 1.1 to fix a handshake error. TLS 1.3, defined in RFC 8446, permits only AEAD cipher suites and removes RSA key exchange and CBC-mode ciphers entirely, which is why an old client that only understands TLS 1.0/1.1 or non-AEAD ciphers cannot negotiate with a modern, correctly hardened server. Every protocol and cipher decision is a trade-off between security, performance, and interoperability with the oldest clients you must still support:

• Security: TLS 1.3-only configurations close the largest attack surface (no downgrade to RC4, 3DES, or CBC padding-oracle vulnerable suites) but will hard-fail any client that cannot negotiate TLS 1.3.
• Performance: TLS 1.3 reduces the handshake to one round trip (versus two for TLS 1.2) and supports 0-RTT resumption, which measurably lowers latency for repeat connections.
• Interoperability: Enterprise middleboxes, legacy IoT devices, and some older mobile OS versions still negotiate TLS 1.2 only. Supporting TLS 1.2 alongside TLS 1.3 (never 1.0/1.1) is the realistic minimum for most public-facing services.

For the full cipher suite component breakdown, the current recommended suites by scenario, and the specific CVEs behind deprecated ciphers, see our companion guide, An Introduction to Cipher Suites. That article owns the “which cipher suite should I choose” question in depth; this guide focuses on diagnosing and fixing a handshake that has already failed.

How Do You Fix an SSL Handshake Failure by Root Cause?

Fix a handshake failure by addressing the specific root cause your diagnostic step identified, not by applying every possible fix at once. The table below maps each symptom to its likely cause, the correct fix, and flags any fix that reduces security so you never apply it without understanding the trade-off.

Symptom	Likely Root Cause	Correct Fix	Risk of a Bad Fix
Browser shows “NET::ERR_CERT_DATE_INVALID” or similar expiry message	Expired server certificate, or client/server clock skew	Renew the certificate before expiry; sync system clock via NTP	Disabling certificate-date checks removes expiry protection entirely, letting revoked or stale certificates through
Handshake fails only on older devices/browsers, works on modern ones	Client stuck on TLS 1.0/1.1 or a legacy-only cipher suite	Update the client OS/browser; if truly unsupportable, isolate that traffic behind a dedicated legacy-compatible endpoint	Re-enabling TLS 1.0/1.1 server-wide reopens BEAST/POODLE-class downgrade risk for every client, not just the legacy one
“unable to get local issuer certificate” in OpenSSL output	Server is not sending the intermediate CA certificate (incomplete chain)	Install the full certificate chain (leaf + intermediate) on the server	Trusting the leaf certificate directly (adding it to a client trust store as a workaround) bypasses CA validation for every future certificate from that server
Handshake fails for one hostname on a multi-domain server, works for others	SNI misconfiguration or a proxy/load balancer stripping the SNI extension	Confirm SNI is forwarded end-to-end; verify the correct certificate is bound to that hostname	Falling back to a single wildcard “catch-all” certificate for every hostname weakens per-domain certificate scoping
Mobile app fails to connect after a routine certificate renewal	Certificate pinning conflict; the app pinned the old key/certificate	Rotate pins in the next app release ahead of renewal, or pin to the CA rather than the leaf certificate	Removing pinning entirely rather than fixing the pin set eliminates a defense against certificate-substitution attacks
Handshake fails intermittently under load, not consistently	Cipher suite negotiation timeout, TLS session resumption cache issues, or overloaded HSM/key-signing operations	Check server TLS termination logs and HSM/signing throughput; tune session resumption	Blanket-disabling session resumption or forward secrecy “to simplify debugging” removes real security properties

What “Quick Fixes” Actually Reduce Your Security?

The fastest way to make an SSL handshake error disappear is usually the worst way to fix it: disabling certificate validation, ignoring hostname verification, or force-enabling deprecated protocols removes the exact protections TLS exists to provide. Three patterns show up constantly in forum answers and should not be used in production:

• Disabling certificate validation in application code (e.g., setting verify=False in an HTTP client, or a custom TrustManager that accepts all certificates). This eliminates protection against man-in-the-middle attacks entirely and is one of the most commonly flagged findings in application security reviews.
• Ignoring hostname mismatch warnings instead of fixing the SAN entries on the certificate. This defeats the purpose of the certificate binding a public key to a specific identity.
• Re-enabling TLS 1.0/1.1 or export-grade/RC4 cipher suites to accommodate one legacy client. RFC 8996 deprecated both protocol versions specifically because of documented, exploitable weaknesses; reintroducing them reopens that exposure for every client that connects, not just the legacy one.

If a genuinely unsupportable legacy client must be accommodated, isolate it: put it behind a dedicated, monitored endpoint with the minimum necessary downgrade, rather than weakening the security posture of the entire service.

How Does Certificate Lifecycle Management Prevent Handshake Failures?

Most recurring, production-impacting handshake failures trace back to certificate lifecycle gaps, not the TLS protocol itself: certificates that expire unnoticed, chains that are installed incompletely, or pins that are never updated on renewal. Under the CA/Browser Forum’s SC-081v3 schedule, maximum public TLS certificate validity drops from 398 days to 200 days starting March 15, 2026, to 100 days starting March 15, 2027, and to 47 days starting March 15, 2029, per SSL.com’s summary of the CA/Browser Forum’s phased schedule and the CA/Browser Forum’s own ballot SC-081v3. At a 47-day maximum lifetime, a certificate renews roughly eight times a year instead of once, and manual tracking is not a viable prevention strategy at that frequency. Preventing handshake failures at scale depends on:

• Automated discovery of every certificate across servers, load balancers, and cloud services, so nothing expires because it was never inventoried.
• Expiry monitoring and alerting well ahead of the renewal window, not the day the handshake starts failing.
• Automated renewal and deployment that installs the full chain (leaf plus intermediate) correctly every time, removing the manual step where incomplete chains get introduced.
• A key-management dependency check: certificate issuance and renewal both depend on the private key and, for HSM-backed CAs, the signing infrastructure being available and correctly provisioned. A stalled key ceremony or an unavailable HSM blocks renewal just as effectively as a forgotten expiry date.

Limitations

• This guide covers the common, diagnosable root causes of SSL/TLS handshake failures; it does not cover application-layer TLS library bugs unique to a specific SDK or runtime.
• Diagnostic commands assume you control, or have permission to test, the server in question. Running verbose TLS diagnostics against systems you do not own or have authorization to test may violate acceptable-use policies.
• The fixes described are general guidance; environments with strict compliance requirements (FIPS 140-3, PCI DSS, HIPAA) should validate any cipher suite or protocol change against their specific compliance obligations before deploying.
• Corporate proxies, antivirus TLS inspection, and captive portals can produce handshake-failure symptoms that mimic the causes in this guide while actually originating from network middleboxes outside the client-server pair; rule these out separately if the standard diagnostics show no issue.

What Would Encryption Consulting Recommend?

We would treat a recurring SSL handshake failure as a certificate lifecycle signal, not a one-off browser glitch. In our engagements, the pattern is consistent: teams firefight individual handshake errors for months before realizing every incident traces back to the same gap, no automated visibility into which certificates exist, when they expire, or whether the chain is installed correctly. CertSecure Manager is built for exactly this: it discovers certificates across your environment automatically, monitors expiry and chain completeness continuously, and automates renewal and deployment so a handshake never fails because a certificate quietly lapsed. For organizations building or replacing the certificate authority (CA) infrastructure issuing those certificates in the first place, our PKI Services team designs and hardens the CA hierarchy, chain distribution, and key-management practices that prevent incomplete-chain and misconfiguration failures before they reach production. Start with the free diagnostic step in this guide; if the pattern repeats across more than a handful of certificates, that is the signal to automate the lifecycle rather than keep debugging individual handshakes.

Frequently Asked Questions

Is “SSL handshake failed” the same error as “SSL handshake failure” or error 525? Yes, in the way most people encounter it. “SSL handshake failed,” “SSL handshake failure,” and Cloudflare’s error 525 all describe the same underlying event, the client and server could not complete the TLS negotiation, though the exact wording and the diagnostic detail available differ by browser, client library, and CDN.

Can a VPN cause an SSL handshake failure? Yes. A VPN can introduce clock skew if it changes the perceived time zone context for a client, route traffic through a proxy that strips the SNI extension, or terminate TLS itself in a way that presents a different certificate than the origin server would. Test the connection with the VPN disabled to isolate whether it is the cause.

Why does the handshake fail on some devices but not others for the same website? This almost always means a protocol version or cipher suite mismatch tied to how old the client’s TLS stack is. Devices running outdated operating systems or browsers may only support TLS 1.0/1.1 or legacy cipher suites that a properly hardened, current server no longer accepts.

Should I just disable SSL/TLS verification to make the error go away? No. Disabling certificate validation removes the protection that confirms you are talking to the real server and not an attacker in the middle. Diagnose the specific cause with openssl s_client or browser dev tools and fix that cause instead; every “quick fix” that disables verification trades a temporary inconvenience for an ongoing, exploitable security gap.

How do shorter certificate validity periods (47-day certificates) affect handshake failures? Shorter validity periods increase the renewal frequency roughly eightfold compared to the old 398-day maximum, which raises the chance of a missed renewal without automation. Organizations that rely on manual certificate tracking will see handshake failures from expired certificates increase as the schedule moves toward 47 days by March 2029; automated discovery, monitoring, and renewal become necessary rather than optional at that cadence.

Conclusion

References

• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3, IETF
• RFC 8996: Deprecating TLS 1.0 and TLS 1.1, IETF
• TLS handshake_failure (Alert 40) reference, protocols.page
• openssl-s_client documentation, OpenSSL Project
• What Is SNI? How TLS Server Name Indication Works, Cloudflare Learning Center
• Certificate and Public Key Pinning, OWASP Foundation
• Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods, CA/Browser Forum
• Preparing for 47-Day SSL/TLS Certificates, SSL.com