The browser refuses before the page loads
ERR_SSL_VERSION_OR_CIPHER_MISMATCH: Reading the Handshake Failure
Diagnose ERR_SSL_VERSION_OR_CIPHER_MISMATCH on a WordPress site, where the browser refuses the connection before a byte of the page loads. Three causes produce that one screen: a protocol version the browser has dropped, a cipher suite neither side shares, or a certificate issued for a different hostname. The checker below tells you which of the three you have.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH means the browser and the server could not agree on how to encrypt the connection. The causes are an obsolete TLS version, a cipher suite the browser no longer accepts, or a certificate that does not cover the hostname being requested.
Is this what you are seeing?
Tick everything that matches. The result names the cause to start with.
Tick a symptom to narrow it down.
What actually causes it
| Cause | How to confirm | Typical fix |
|---|---|---|
| Obsolete TLS version | An SSL Labs test reports TLS 1.2 and 1.3 as unsupported | 30 min |
| Unsupported cipher suite | The same test lists only ciphers marked weak | 30 min |
| Hostname mismatch | Read the certificate subject and SAN entries against the URL being requested | 15 min |
| Certificate not installed on this host | The server presents a default or self-signed certificate instead | 20 min |
The connection fails before WordPress runs
This error happens during the TLS handshake, which is over before a single byte of the page is requested. WordPress is not involved, no plugin can influence it, and nothing in wp-admin will change the outcome.
That narrows the causes usefully: the server offers protocol versions or ciphers the browser rejects, or it presents a certificate for a hostname other than the one being asked for.
The hostname is the usual answer
A certificate covers the exact names listed in its subject and SAN fields. A certificate for example.com does not cover www.example.com, shop.example.com or anything else unless those names are on it.
The symptom is distinctive: one form of the URL works and another does not. It surfaces most often the day a certificate renews with a narrower name list than the one it replaced, or after a subdomain is added and nobody reissued.
Read the certificate before changing any server configuration. It takes a minute and it resolves the majority of these cases.
A handshake that fails in the browser is a certificate warning. One that fails server-side, on an outbound call PHP makes, is a fatal – and reaches the visitor as a 500 internal server error or, with error output hidden, as a white screen. The WordPress error index separates them.
How to fix it
- Run an external SSL test first. SSL Labs or testssl.sh reports the protocol versions, the cipher list and the certificate hostnames in one pass. Every branch below follows from that output, and guessing without it wastes the afternoon.
- Check which hostnames the certificate covers. A certificate for
example.comdoes not coverwww.example.comunless the SAN list says so. This is the most common single cause and the fastest to confirm. - Enable TLS 1.2 and 1.3, and disable everything older. Current browsers refuse TLS 1.0 and 1.1 outright. Servers left on old defaults after a migration produce this error for every visitor at once.
- Replace the cipher suite list with a current one. Mozilla publishes maintained configurations for every common server. Copy the intermediate profile rather than assembling a list by hand.
- Reissue the certificate when the hostnames are wrong. Include every hostname the site answers on, the bare domain and www included, then reload the server rather than only installing the file.
- Re-test from outside and from a second network. A cached handshake in your own browser hides a fix and hides a failure equally well.
When that fix does not hold
Do not disable HTTPS to get the site back. Every browser now marks plain HTTP as insecure, forms stop being trusted, and any HSTS header the site sent previously keeps browsers refusing to connect over HTTP anyway. Fix the handshake rather than removing it.
Questions people ask before calling
Why do some visitors reach the site and others cannot?
Browsers differ in which protocols and ciphers they still accept. A server offering only obsolete options works for whoever has not updated and fails for everybody else, which makes the reports look random.
Does this mean the certificate expired?
No. An expired certificate produces a different, clearer warning. This error is about the encryption negotiation itself, or about a certificate that does not cover the hostname requested.
Can it be fixed from inside WordPress?
No. TLS is server configuration and WordPress has no part in it. Any plugin claiming to fix this is changing site URLs, which is a different problem.
How long does a fix take to reach everyone?
Immediately for new connections. Browsers cache handshake results briefly, so test in a private window or from another network rather than trusting your own first attempt.
When it needs handing over
WordPress security service work serviceScan any WordPress site for the exposures attackers actually use — version disclosure, user enumeration, open XML-RPC, missing headers, outdated plugins with known CVEs. Then we…
More errors