SSL Handshake Failed: Causes and Fixes

Where you see the error and what it means

Each client words the failure differently:

If the browser shows "Your connection is not private" instead, the handshake reached the certificate check and the certificate was rejected: see Your connection is not private.

Solutions for website visitors

Open the same website on another device and network, for example your phone on mobile data. If it fails there too, the website is at fault and only its owner can fix it. If it works elsewhere, check your own device:

1. Check the date and time. A wrong clock makes valid certificates look expired. Turn on automatic date and time, then restart the browser.
2. Update your browser and operating system. Old browsers and systems may not support TLS 1.2 or TLS 1.3, which most websites require today.
3. Check your antivirus or firewall. Features called "HTTPS scanning" or "SSL inspection" sit between you and the website. Turn the feature off for a moment, or update the product, and reload.
4. Turn off VPN, proxy and browser extensions. Test in a private window with extensions disabled. If you changed the browser's TLS settings, reset them to the defaults.
5. Choose a client certificate if the site asks for one. Some company, bank or government portals require a personal certificate. Without it, or with the wrong one, the server ends the handshake. On a company computer, ask your IT team.

Website owners: test the handshake with openssl s_client

Start with our free SSL Checker. For more detail, run openssl s_client from any Linux or macOS terminal (replace www.example.com with your domain):

openssl s_client -connect www.example.com:443 -servername www.example.com
openssl s_client -connect www.example.com:443 -tls1_2
openssl s_client -connect www.example.com:443 -tls1_3

The first command shows the certificates the server sends, the negotiated protocol and cipher, and a line such as Verify return code: 0 (ok). The other two test TLS 1.2 and TLS 1.3 separately; a "handshake failure" alert means the server rejected that version or the offered ciphers. Type Q and press Enter to quit. -servername sends SNI, which OpenSSL 1.1.1 and newer also do by default for host names.

Enable TLS 1.2 and TLS 1.3 with modern ciphers

Current browsers no longer accept TLS 1.0 and 1.1. If the server offers only old protocols or weak ciphers, the handshake fails.

• Nginx: set ssl_protocols TLSv1.2 TLSv1.3; in the server block.
• Apache: set SSLProtocol -all +TLSv1.2 +TLSv1.3 (TLS 1.3 needs Apache 2.4.36 or newer with OpenSSL 1.1.1).
• Ciphers: remove custom cipher lists you do not need, or use a current recommended list. A list that is too strict locks clients out too.

Reload the web server and repeat the tests from step 3.

Configure SNI and serve the right certificate

With Server Name Indication (SNI) the client tells the server which website it wants, so a server with many sites on one IP address can pick the right certificate. Without a virtual host for the requested name, the server falls back to a default site with no certificate or the wrong one. Make sure every domain and its www version has its own HTTPS virtual host (Nginx server_name, Apache ServerName and ServerAlias) with the correct certificate. Very old clients that do not send SNI cannot reach SNI-only sites; read more in Dedicated IP vs SNI.

Install a valid certificate with the full chain

An expired certificate, a certificate for another name or a missing intermediate makes the client reject the server. Browsers usually show a certificate warning such as NET::ERR_CERT_DATE_INVALID or NET::ERR_CERT_AUTHORITY_INVALID, while curl, Java, mobile apps and API clients often report a handshake or verification error.

1. Install the intermediate certificate next to your certificate (on Nginx, append it to the certificate file). Download the right bundle from our intermediate and root certificates pages.
2. Renew an expired certificate and install it on every server and load balancer that serves the site.
3. Replace self-signed certificates on public sites. A trusted domain-validated certificate such as Sectigo PositiveSSL costs from $16.00 per year and is issued in minutes.

If the server requires client certificates (mutual TLS), visitors without one cannot finish the handshake, so require them only where needed.

Fix Cloudflare error 525

Cloudflare shows error 525 only when the SSL/TLS encryption mode is Full or Full (strict) and the handshake between Cloudflare and your origin server fails. Check the origin with your host:

1. A certificate is installed on the origin. Full mode accepts any certificate, even a self-signed or expired one, but there must be one. Full (strict) needs a valid certificate from a publicly trusted CA or a free Cloudflare Origin CA certificate that matches the hostname; an invalid certificate there leads to error 526 instead.
2. Port 443 is open (or your custom HTTPS port) and the web server listens on it with SSL.
3. The origin supports SNI and has an HTTPS virtual host for the hostname.
4. The ciphers match. The origin must support at least one cipher suite that Cloudflare uses (see step 4).

To test the origin directly, run the first command from step 3 with the origin's IP address in -connect and your domain in -servername. If the errors come and go, check the web server's SSL error log at those times.