An SSL handshake failure means the browser (or app) and the server could not agree on how to set up an encrypted connection, so the connection was dropped before any page loaded. The fix depends on which side broke the negotiation: a certificate that is wrong or expired, a protocol or cipher the two sides do not share, a wrong clock, or something in the middle, such as a firewall, antivirus or proxy, that interrupted the exchange. This guide shows you how to tell which one you have in a few minutes and what to change.
TL;DR
- A handshake failure means the client and server could not establish a secure connection during the opening negotiation, and the connection is terminated (Apigee Docs).
- The usual suspects are an invalid or expired certificate, mismatched protocol versions or cipher suites, a wrong device clock, and interference from proxies, firewalls or antivirus software.
- If only some visitors see the error, suspect their network or security software. If everyone sees it, suspect your certificate or server configuration.
- On a site behind Cloudflare, "Error 525" means Cloudflare could not complete the handshake with your origin server. Install a valid certificate there, open port 443 and check cipher and SNI support.
- Stuck after the checks below? Send your hosting provider the exact error text, the time and the domain.
Table of Contents
- What an SSL handshake failure actually means
- The first question: who sees it?
- Common causes, in the order to check them
- Fixes for visitors and for the device you are testing on
- Fixes for site owners: diagnose the server side
- Cloudflare SSL handshake failed: fixing Error 525
- SSL handshake timeout: when the negotiation never finishes
- Our perspective: where handshake problems really come from on small business sites
- Let us handle the certificate and server side
- When to contact your hosting provider
- Prevent handshake errors from coming back
- FAQ
- Sources
What an SSL handshake failure actually means
Before any page is sent over HTTPS, the browser and the server run a short negotiation. They agree on a protocol version and a cipher suite, the server presents its certificate, and the browser checks it. Only then do they start exchanging encrypted data. If any step fails, the connection is closed and you get an error instead of a page.
The name still says "SSL", but modern connections use TLS, the successor protocol. The two terms are used interchangeably in error messages, which is why people search for both "SSL handshake failed" and "TLS handshake failure". They are the same class of problem.
During the check, the client compares the certificate's digital signature against the roots it trusts and looks at whether the certificate has expired or been revoked, according to Palo Alto Networks. Any mismatch can end the conversation right there.
You will see the failure worded in many ways depending on the software:
- Browsers: "This site can't provide a secure connection" or ERR_SSL_PROTOCOL_ERROR.
- Cloudflare-fronted sites: "Error 525: SSL handshake failed".
- Servers and tools: an alert such as handshake_failure (code 40), which signals that the two sides failed to negotiate security parameters, or bad_certificate (code 42), which points at a certificate problem, as listed by Broadcom.
- Java, Python, curl and API clients: a plain "handshake failure" in a stack trace.
That last group matters. If the error appears in a script, plugin or payment integration rather than in a browser, the same logic applies, but the client is your own code or a library with its own list of supported protocols.
The first question: who sees it?
The most useful thing you can do before touching any setting is work out the scope. Sectigo's CTO, Nick France, makes the point in Sectigo's guide to handshake errors: identifying the root cause comes first, because server-side problems need configuration changes while client-side ones usually involve browser or environment settings.
Run this quick triage:
| What you observe | Likely side | Where to look first |
|---|---|---|
| Every visitor, every device, every network | Server | Certificate, installed chain, protocol and cipher settings |
| Only you, only one computer | Client | Device clock, browser, antivirus or HTTPS scanning |
| Only people on one office or school network | Network | Corporate firewall or proxy, TLS 1.3 compatibility |
| Comes and goes for the same person | Network or server load | Origin error logs, HTTP/3, timeouts |
| Only on a Cloudflare-proxied domain | Origin | Origin certificate, port 443, SSL mode |
| Only an API client or script | Client library | Supported TLS versions, trust store, SNI |
Two tests settle most of it. Open the site on your phone using mobile data instead of Wi-Fi. Then open it from a different browser or device. If the error disappears, the problem is local to the first device or network and your server is probably fine.
Common causes, in the order to check them
1. A certificate problem
This is the most common server-side cause. The certificate may be expired, issued for a different domain name, missing its intermediate certificates, or simply not installed for the domain being requested. The client checks validity and trust during the handshake, so a failed check ends the connection.
If your certificate is the suspect, our walkthrough on fixing SSL certificate errors in minutes covers the checks and commands. If you are not sure what type of certificate your site needs, the types of SSL certificates for small businesses explains the differences, and our step-by-step SSL setup guide helps if the certificate was never installed correctly.
2. Protocol or cipher mismatch
The client and server each support a list of protocol versions and cipher suites. If the lists do not overlap, there is nothing to agree on and the handshake fails. A very old server that only speaks a legacy protocol will fail against a modern browser. A very old client will fail against a hardened server that has switched off legacy options. Apigee's troubleshooting page names protocol and cipher mismatch among the standard causes, alongside an incorrect certificate and servers that require SNI.
3. SNI not supported or not sent
Server Name Indication lets one IP address host many HTTPS sites, because the client tells the server which hostname it wants during the handshake. If a client does not send it, or the server does not support it, the server may present the wrong certificate or none at all. This shows up mostly with old libraries and with scripts that connect to an IP address instead of a hostname.
4. Wrong date or time on the device
Certificates have validity windows. If a computer's clock is far off, a perfectly good certificate looks expired or not yet valid. Sectigo lists correcting the system date and time as a practical fix for failures caused by this mismatch. It is the first thing to try when the error appears on one machine only, particularly after a dead battery, a virtual machine restore or a long time offline.
5. Something in the middle
Proxies, firewalls and antivirus tools that inspect encrypted traffic can reset a connection halfway through the negotiation, as Host-Tracker explains. That makes the failure look like a server problem when it is actually a local one. Temporarily disabling HTTPS scanning in security software, or switching networks, is a quick way to confirm it.
For a wider look at why encrypted connections matter to a business site and what goes wrong when they break, see this overview of website security and customer trust.
Fixes for visitors and for the device you are testing on
If you are the person seeing the error, work through these in order. Each takes under a minute.
- Reload on another network. Mobile data, a different Wi-Fi network or a VPN. If it works, the original network is interfering.
- Check the date, time and time zone and turn on automatic time setting.
- Try a private window or a different browser. This rules out a bad extension or a cached certificate problem.
- Pause antivirus HTTPS scanning or a local proxy for a moment, then test again. Turn it back on afterward.
- Update the browser and operating system. Outdated software may lack protocols or root certificates that sites now require.
- Restart the router if the failure is intermittent and affects many sites, not just yours.
If the issue affects only certain visitors of your site, Cloudflare's guidance on ERR_SSL_PROTOCOL_ERROR suggests testing from a different network or a VPN, and temporarily disabling HTTP/3 to see whether network-level interference is involved. The same page recommends looking at TLS 1.3 compatibility when visitors on corporate networks or with specific security software keep failing consistently.
Fixes for site owners: diagnose the server side
If everyone fails, the work is on your server. Begin with the cheapest checks and move toward the logs.
Confirm the certificate is valid and complete
Check the expiry date, that the certificate matches the exact hostname (including the www version if you use it), and that the full chain is installed, not only the leaf certificate. If you use auto-renewing certificates, confirm the renewal actually ran. A failed renewal leaves a site working one day and failing the next.
If you are choosing between free and paid options, our comparison of Let's Encrypt and paid SSL lays out what small businesses actually need.
Run the handshake by hand
A manual handshake from the command line shows exactly where negotiation stops, which helps separate protocol trouble from certificate trouble. Host-Tracker makes this point in its handshake diagnosis guide. A set of command line checks for developers walks through five of them.
The usual tool is OpenSSL. A basic test looks like this:
openssl s_client -connect example.com:443 -servername example.com
Read the output for three things: whether a certificate chain is returned, whether verification reports an error, and which protocol and cipher were negotiated. If the command returns an alert immediately with no certificate, the server rejected the hello message, which points at protocol, cipher or SNI settings. If it returns a certificate with a verify error, you have a certificate or chain problem.
You can then force a specific version, for example by adding -tls1_2 or -tls1_3, to see which versions your server accepts. If TLS 1.2 works and 1.3 does not, or the other way round, you have found the mismatch.
Check that port 443 is open and listening
A firewall rule, a security group or a stopped web server service can leave port 443 unreachable or half-working. Confirm that the web server is listening on 443 and that no firewall rule drops traffic from the sources that need it, including any proxy or CDN in front of the site.
Read the error logs
Logs show what the browser cannot. For intermittent failures, Cloudflare advises reviewing origin server error logs, including Apache mod_ssl logs or Nginx error logs. Look for entries at the time of a failed request: certificate load errors, no shared cipher, or unsupported protocol messages.
Check redirects and mixed configuration
A misconfigured redirect from HTTP to HTTPS can create loops or send visitors to a hostname that has no certificate. Our copy-ready HTTPS redirect rules for Apache and NGINX, plus a WordPress checklist, help you rule that out.
Cloudflare SSL handshake failed: fixing Error 525
If your visitors see "Error 525: SSL handshake failed" on a site that uses Cloudflare, the message is specific. It means the handshake between Cloudflare and your origin server failed. The browser-to-Cloudflare leg is fine. The failure is on the second leg, and it happens when the SSL mode is Full or Full (Strict), which require the origin to speak HTTPS.
Cloudflare's own Error 525 documentation lists what to verify at the origin:
- A valid SSL certificate is installed for the domain.
- Port 443 (or the custom secure port you set) is open and reachable.
- The origin supports SNI.
- The origin's cipher suites are compatible with what Cloudflare requires.
- The server logs show no handshake errors during the failure window.
A practical order of operations:
- In the Cloudflare dashboard, note which SSL/TLS mode the domain uses.
- Visit your origin directly (by its IP with the right hostname, or by temporarily bypassing the proxy) and see whether a certificate is presented.
- If no certificate is installed, install one on the origin. Then retest.
- Make sure the origin certificate covers the hostname. A mismatch with Full (Strict) will fail.
- Confirm 443 is open in the server firewall and that Cloudflare traffic is not being blocked.
- Review the origin logs for the exact time of the error.
One piece of advice floats around forums: switch the mode to Flexible to make the error vanish. It does make the page load, because Cloudflare then talks to your origin over plain HTTP. But that removes encryption on the second leg, so treat it as a short diagnostic step at most, not a fix. Install the origin certificate and go back to a strict mode.
To see how widespread the problem is, Cloudflare notes that analytics showing an originResponseStatus of 0 can help you tell whether handshake failures are limited to specific endpoints. That helps when only one subdomain or path fails.
For 525 specifically, Cloudflare's guidance is to contact your hosting provider so the common origin-side causes are checked.
SSL handshake timeout: when the negotiation never finishes
A handshake timeout is a different shape of failure. Nothing is wrong with what the two sides said. The exchange simply did not complete within the allowed time. Sectigo describes it as a handshake that takes longer than the set limit, often because of network latency, heavy server load or interference from devices such as firewalls along the path.
Work on it by locating where the delay is:
- Server load. If the server is overloaded, it may be too slow to answer the opening message. Check CPU, memory and the number of simultaneous connections around the time of failures. An undersized plan is a common reason.
- Network path. Test from several networks and locations. If one region or one provider times out and others do not, the problem sits on the route, not on your server.
- Middleboxes. A firewall doing deep inspection can stall or drop the handshake. Check its logs and rules.
- Timeout values. If a client or proxy has an aggressively short timeout, raise it modestly while you investigate rather than leaving it unchanged.
Timeouts at the gateway level can also show up as a different symptom for visitors. If your pages return errors rather than a handshake message, our guide to the 504 Gateway Timeout covers that related case.
Our perspective: where handshake problems really come from on small business sites
When site owners write to us about handshake errors, the cause is rarely exotic. Most often a certificate was never issued for the exact hostname, a renewal quietly failed, or a CDN or proxy was switched to a strict mode before the origin was ready. Those are configuration order problems, not mysteries.
Our advice is to treat the certificate as part of the site's regular upkeep, not a one-time setup. Know where your certificate is issued, when it renews, and who is told if it does not. Test after any change to DNS, a proxy, a redirect or a server migration, because each of those can break the chain without touching the pages themselves.
The second habit is to diagnose before you change anything. Decide whether the problem is on the visitor's side, on the network or at the origin. Run a manual handshake. Read the log. A five-minute check beats an hour of toggling settings that were fine.
Our sites are managed by experienced SRE and DevOps engineers in the EU and US, and we include free migrations, so a move to a new server does not have to mean a broken certificate. We also back new hosting plans with a 30-day money-back guarantee.
— Ihor
Let us handle the certificate and server side
If you would rather not debug ciphers and chains yourself, a host that sets up HTTPS correctly from day one removes most of this list. inSave Hosting offers free SSL certificates, LiteSpeed-based performance, daily backups, free migration and a unified dashboard across shared hosting and WordPress hosting, with VPS and dedicated options when you need more control. For certificate options, see our SSL certificates page.
Already a customer and seeing an error you cannot trace? Log in to your account and send support the domain, the exact message and the time it happened.
When to contact your hosting provider
Do not spend a whole afternoon on this if the checks above point at the server. Contact your host or server administrator when:
- A valid certificate looks installed but the handshake still fails for everyone.
- You see Error 525 and cannot reach or inspect the origin configuration yourself.
- The logs show cipher, protocol or SNI errors you are not sure how to change safely.
- The failures appear after a migration, a plan change or a server update.
Give them the exact error text, the domain, the time of the failure, whether it affects all visitors or some, and the output of your manual handshake test. That turns a vague ticket into a quick answer.
If you have ruled out the origin and the problem is a protocol error affecting some visitors, Cloudflare says to contact its support with packet captures taken from an affected visitor.
Prevent handshake errors from coming back
- Turn on automatic renewal and check that it works before the expiry date, not after.
- Keep the full chain installed and retest after each renewal.
- Do not leave old protocols as your only option. Support current TLS versions on the server, and test your site with an older client occasionally if you serve people who use one.
- Change one thing at a time in a proxy or CDN, and test between changes.
- Monitor from outside. An uptime and certificate monitor that alerts you before expiry saves a lot of lost visits.
- Revisit the basics with our explainers on what an SSL certificate is and how SSL encryption works for webmasters.
FAQ
How do I fix an SSL handshake failure?
First decide who is affected. If only one device or network fails, check the clock, antivirus HTTPS scanning and browser, and try another network. If everyone fails, check the certificate's validity, hostname and chain, then confirm port 443 is open and that protocol and cipher settings overlap with what clients support. A manual OpenSSL test shows where the negotiation stops.
What causes a TLS handshake failure?
The common causes are protocol or cipher mismatches, invalid or expired certificates, incorrect device clocks, and interference from proxies, firewalls or antivirus software, as Host-Tracker lists. A server that needs SNI can also fail with clients that do not send it.
What does Cloudflare Error 525 mean?
It means Cloudflare could not complete an SSL handshake with your origin server while using Full or Full (Strict) mode. Install a valid certificate on the origin, open port 443, confirm SNI support and check that cipher suites are compatible. Your hosting provider can verify these quickly.
Is an SSL handshake timeout the same as a handshake failure?
It is a related but separate case. A failure means the two sides could not agree or a check failed. A timeout means the process did not finish in the allowed time, often from latency, heavy server load or a firewall in the path. The fix is to find where the delay occurs.
Should I switch Cloudflare to Flexible to get rid of the error?
Only briefly, to confirm the problem is at the origin. Flexible stops encrypting the connection between Cloudflare and your server, so the proper fix is a valid certificate on the origin and a return to a strict mode.
Sources
- TLS/SSL Handshake Failures, Apigee Docs
- SSL handshake failed: causes and how to diagnose it, Host-Tracker
- SSL/TLS handshake errors: causes and how to fix them, Sectigo
- What Is the TLS Handshake?, Palo Alto Networks
- SSL alert codes, Broadcom
- Error 525, Cloudflare Support docs
- Troubleshoot ERR_SSL_PROTOCOL_ERROR, Cloudflare
- Cloudflare 5xx errors, Cloudflare Support docs
- Fix SSL handshake failures: 5 command line checks
- Website security: safeguarding brands and customer trust