How to fix SSL handshake failed on WordPress

A customer sends a screenshot that says “SSL handshake failed.” The site loads fine on your laptop, the certificate dashboard says valid, and nobody has touched the theme. Don’t reinstall the certificate or start deactivating plugins yet. A WordPress site has at least three connections that can fail this way, and each has a different fix and a different person who can fix it.

An SSL handshake is the negotiation two machines go through before they send each other encrypted data. The protocol is really called TLS now, but the old name stuck. The two sides have to agree on a protocol version and a cipher, and the client has to accept the server’s certificate for the hostname it asked for. All of this happens before WordPress sees the request. So when the handshake fails on page load, a plugin or theme setting is rarely the fix.

Which connection failed? Start with where the message appeared

Where the error shows up tells you more than its wording does. Match what you see to one of these rows before you touch anything.

Where you see it	What it looks like	Connection that failed	Who usually fixes it
A Cloudflare-branded error page	“Error 525: SSL handshake failed”	Cloudflare to your server	Your host
Site Health, a plugin log, a failed payment, licence activation or import	cURL error 35	WordPress to another service	Your host, sometimes the remote vendor
The browser, for every visitor	ssl_error_rx_record_too_long or a certificate warning	Browser to your server	Your host
The browser, on one device or network only	A handshake or certificate error that others don’t see	Browser to your server	The visitor’s device or network

Write down four facts: the exact message and when it happened, whether it hits everyone or one device, whether a CDN or proxy like Cloudflare sits in front of the site, and whether it fails on page load or only on an outbound action such as checkout or email. If the browser can’t find the site at all, that is a DNS problem, not a handshake problem. The guide to fixing DNS_PROBE_FINISHED_BAD_CONFIG errors covers that case.

Cloudflare Error 525 points at your server, not WordPress

Cloudflare’s Error 525 documentation defines it as a failed TLS handshake between Cloudflare and your origin server. It can only happen when the zone’s SSL/TLS mode is Full or Full (strict). Cloudflare lists four causes: no valid certificate on the origin, port 443 (or your configured secure port) closed, no SNI support, and no cipher suite both sides share.

That explains why the padlock can look fine while the site is down. Visitors see Cloudflare’s edge certificate. A 525 is about the certificate on your own server, which visitors never see. On WordPress sites the usual cause is a certificate on that server that expired, went missing after a migration, or was issued for a different hostname.

1. Test the origin directly, keeping your hostname. With your server’s IP in place of the example address, run curl -v --resolve example.com:443:203.0.113.10 https://example.com/ or openssl s_client -connect 203.0.113.10:443 -servername example.com -showcerts. Check whether the connection completes, the certificate’s dates, the names it covers, and whether the chain verifies (Verify return code: 0 (ok)). Don’t leave out -servername. Without SNI, a shared server can hand back its default certificate and send you down the wrong path.
2. If there is no valid certificate, install one for the exact hostname. Use a Let’s Encrypt certificate through your host, or a Cloudflare Origin CA certificate. Cloudflare suggests the Origin CA option when the origin has no certificate at all.
3. If the connection never gets as far as a certificate, ask the host to check that something is listening on port 443, that no firewall is dropping Cloudflare’s requests, and that SNI and cipher settings are in place.
4. If the error comes and goes, compare the failure times with the origin’s SSL error logs, as Cloudflare recommends. Twenty good responses in a row do not prove the problem is gone.
5. Once the origin has a valid certificate, set the mode to Full (strict). Full encrypts the connection but does not validate the certificate. Full (strict) validates it and accepts either a public CA certificate or a Cloudflare Origin CA certificate.

Pausing Cloudflare, or switching the DNS record from proxied to DNS-only, is a good test. If the site loads over HTTPS with the proxy off, the origin is reachable and the problem is in the Cloudflare-to-origin leg. Treat it as a test only. Fix HTTPS at the origin, then turn the proxy back on.

Why switching to Flexible is the wrong fix

Cloudflare’s Flexible mode sends traffic from Cloudflare to your server over plain HTTP. The 525 goes away because no handshake is left to fail. The broken certificate is still broken, and the traffic between Cloudflare and your host is now unencrypted. If your server or an SSL plugin redirects HTTP to HTTPS, every request bounces back and forth in a redirect loop that WordPress can’t break. Dropping from Full (strict) to Full lowers security in the same way without repairing anything.

cURL error 35 means WordPress can’t reach another service

Here the site loads for visitors. What fails is a request your server makes to somewhere else: a payment gateway, a licence server, an update check, an SMTP relay or a webhook. Common versions of the message include OpenSSL SSL_connect: Connection reset by peer, wrong version number, Peer reports incompatible or unsupported protocol version and gnutls_handshake() failed.

Really Simple Security’s article on cURL error 35 says the error appears when PHP’s cURL library can’t make the SSL connection. Its first step is updating cURL and PHP, and its second is asking your host. Practitioners add a few more causes: an outdated OpenSSL library or CA bundle, a remote service that requires a newer TLS version than your server offers, and a firewall, mod_security rule or security product that interferes with outbound traffic.

That last cause can come from a surprising place. In one WordPress.org support thread, email failed on more than ten sites, and the cause turned out to be Norton 360’s outbound email scanning.

Two checks narrow it down:

• Site Health. Go to Tools > Site Health. The WordPress support handbook explains that Health Check tests two separate things: whether visitors reach the site securely, and whether WordPress can talk securely to outside services. A failure in the second test confirms an outbound problem.
• One plugin or all of them. If only one plugin’s feature fails, such as a social login or a single licence activation, while updates and other connections work, the cause is probably that plugin or its vendor’s server. Contact the vendor early. If the remote end is the problem, nothing you change on your own site will fix it.

Don’t make the error go away by turning off certificate verification, for example by setting sslverify to false or disabling CURLOPT_SSL_VERIFYPEER. Your server would then accept any certificate, including a forged one, on the same connections that carry payments and licence keys.

When the browser refuses the connection

Every visitor sees it

WooCommerce’s documentation for ssl_error_rx_record_too_long describes a browser that expected HTTPS and got unencrypted data back. The listed causes are no certificate, a wrong port setting, a misconfigured Apache VirtualHost for port 443, or WordPress URLs switched to HTTPS before the server could serve HTTPS. That last one can trigger the error on every page request.

The order matters. Your host gets HTTPS working on the server first. Only then do you change the WordPress Address and Site Address under Settings > General to https://, which is the sequence WooCommerce’s SSL and HTTPS guide gives. If those two fields are greyed out, WordPress.org’s Settings General documentation explains why: WP_HOME or WP_SITEURL is defined in wp-config.php, so you edit them there. The article on securing Apache for WordPress walks through the full HTTPS sequence on an Apache server.

Only one device or network sees it

If the site works everywhere except one phone or one office, look at that phone or office. Check that the device’s clock is correct, update the browser, and try a private window with extensions off. Then try mobile data instead of the office Wi-Fi. Antivirus software and corporate networks that inspect TLS traffic can swap in their own certificates or break the negotiation. Turn security software off only for a quick test. If that was the cause, allowlist the site and switch the protection back on.

Lookalikes that are not handshake failures

“Not Secure” after installing a certificate. This is mixed content. The page is HTTPS but still loads some images, scripts or stylesheets over http://. WooCommerce’s fix is to change those URLs to HTTPS or to relative paths. A database search-replace does this more cleanly than a plugin that rewrites URLs on every page load.

Too many redirects. Two layers are forcing HTTPS against each other. WooCommerce’s SSL guide names Easy HTTPS Redirection conflicting with Force SSL as one example. Pick one layer to handle HTTPS and switch off the others.

An expired-certificate warning. Renew the certificate, then find out why automatic renewal failed. A common reason is a firewall rule that closed port 80, which Let’s Encrypt’s HTTP-01 challenge needs.

When to stop and hand it to your host

Stop once the fix involves installing a certificate, changing server or VirtualHost configuration, opening a port, changing a firewall, or upgrading PHP, cURL or OpenSSL. That work belongs to your host or server admin, and a settings change in WordPress can’t stand in for it. Send them a ticket they can act on:

• the affected hostname and the exact error text, with times and time zone;
• whether it hits every visitor or one device, and on page load or on an outbound action;
• your Cloudflare SSL/TLS mode, and whether the site loads with the proxy paused;
• the output of the curl or openssl test and the Site Health message.

If you’d rather not run these checks yourself, SiteSelf can take on fixing errors on your WordPress site from a chat request. It uses hosting (SSH) access for server-side work, reports what it found and checked, and does not change settings in your Cloudflare account. Once the site is back, add certificate expiry and renewal checks to your WordPress website care plan so the next expiry doesn’t take the site down first.