TLS handshake failed

DomainDash couldn't complete the TLS handshake with your server. This is the generic fallback when the handshake fails for a reason that doesn't map to one of the more specific SSL errors.

Symptom

• DomainDash flags the SSL check as Invalid with error code tls_error
• Visitors may see a generic browser warning, or in some cases a connection-failed page rather than an SSL warning
• Running openssl s_client -connect example.com:443 -servername example.com </dev/null shows an error before the certificate is presented: e.g. ssl handshake failure, no cipher match, protocol version

What "TLS errors" actually mean

"TLS error" (or "SSL error") is an umbrella for anything that goes wrong while setting up the secure connection, before a single byte of your page is sent. Most of the time it's a handshake failure: the browser and server can't agree on a protocol version or cipher, so the connection never opens. That's what this page covers.

But the same wording often gets used for problems that are really about the certificate, not the handshake. Here's how to tell which one you've got:

What you're seeing	It's probably…	Go to
"handshake failed", "no cipher", "protocol version", where the connection drops before any certificate appears	A handshake / config error	This page
"certificate has expired", NET::ERR_CERT_DATE_INVALID	An expired or not-yet-valid certificate	Validity
"not trusted", "unknown issuer", "self-signed"	An untrusted or self-signed certificate	Trust
"not valid for this name" / ERR_CERT_COMMON_NAME_INVALID	A hostname mismatch	Hostname
The connection just hangs and times out, with no TLS error at all	A connection timeout, not TLS	Uptime

If yours is a genuine handshake failure, read on.

What it means

The TLS handshake is the negotiation that happens at the very start of a secure connection: the client and server agree on a protocol version and a cipher suite, then exchange certificates. If any step fails before certificate validation, you get tls_error. A failed handshake means the client and server couldn't agree on how to talk, so the connection never gets off the ground and visitors can't reach you. It's usually a server-side configuration issue, which means it's firmly in your hands to fix.

Common causes

• Protocol version mismatch. Your server only allows old TLS versions (1.0/1.1) that modern clients refuse, or only allows TLS 1.3 with no fallback for clients that still need 1.2. Most checkers (including DomainDash) require TLS 1.2 or 1.3.
• Cipher suite mismatch. Your server only supports ciphers that the client doesn't, or vice versa. Often a result of overly restrictive ssl_ciphers config.
• SNI (Server Name Indication) issue. Your server requires SNI but the client isn't sending it, or vice versa. Rare in 2026 but still possible with very old clients.
• Wrong certificate chain causing immediate handshake abort. Some servers terminate the handshake early if they can't load their own cert correctly.
• The TLS port is being intercepted. A captive portal, transparent proxy, or buggy load balancer is interrupting the handshake.
• Server overloaded. Under heavy load, some servers drop TLS handshakes, and the symptoms look identical to a config issue.
• You disabled TLS entirely. The server is serving plain HTTP on port 443 (yes, this happens).

Common TLS error messages

The exact wording depends on the client or tool, but nearly all of these point back to the same handful of causes above:

Message	What it usually means
SSL_ERROR_HANDSHAKE_FAILURE, "handshake failure", "handshakefailure"	No shared protocol or cipher. The two sides couldn't agree. Enable TLS 1.2 + 1.3 and a modern cipher list.
"ssl handshake failed", "peer failed to perform tls handshake"	The handshake was rejected or cut short, usually a protocol/cipher mismatch, an aborted chain, or a proxy in the way.
ssl_do_handshake() failed (nginx)	nginx couldn't complete the handshake. Check the upstream/origin's TLS settings, not just the edge.
"no cipher match", "no shared cipher"	The cipher lists don't overlap. Widen ssl_ciphers to a modern default.
tlsv1 alert protocol version, "protocol version"	One side only offers a TLS version the other refuses (often old TLS 1.0/1.1). Move both to 1.2/1.3.
"the tls connection request has failed"	A generic wrapper around any of the above. Work through the steps below.

Whichever message you have, the diagnosis is the same: find out which protocols and ciphers each side allows.

How to fix

1. Test with explicit protocol versions to narrow down the cause:

   openssl s_client -connect example.com:443 -servername example.com -tls1_2 </dev/null
   openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null

   If only one version works, you know your server isn't supporting the other.

2. Run an SSL Labs scan (https://www.ssllabs.com/ssltest/). It tells you exactly which protocols and ciphers are enabled, and which clients can or can't connect.

3. For nginx, check your config:

   ssl_protocols TLSv1.2 TLSv1.3;
   ssl_ciphers HIGH:!aNULL:!MD5;

   If ssl_protocols only lists one version, add the other (TLS 1.2 + 1.3 is the modern default). After editing, run nginx -t then sudo systemctl reload nginx.

4. For Apache, check SSLProtocol in your config. It should be all -SSLv3 -TLSv1 -TLSv1.1 at minimum.

5. If the issue only happens during load, investigate server resources. CPU saturation during the TLS handshake is a classic symptom of an undersized server.

6. If you're behind a CDN or reverse proxy, check the proxy's TLS settings, not just the origin's. The handshake DomainDash sees is with the proxy.

How to verify

1. Re-run the openssl protocol checks from step 1. Both TLS 1.2 and 1.3 should complete without errors.
2. Run an SSL Labs scan. Aim for at least an A grade.
3. Open the site in an incognito window. The padlock should appear cleanly.
4. Open the site in DomainDash. It re-checks SSL on its normal schedule, so once the handshake succeeds the SSL check returns to Valid on its own (and the site to Healthy once every check is green), with nothing to click.

Related

• Hostname doesn't match certificate — sometimes presents as a handshake failure
• Certificate signed by an untrusted authority — chain issues can also abort the handshake
• Certificate signature is invalid — signature errors during handshake
• Certificate not yet valid — if the connection completes but the browser rejects the certificate's dates, it's a validity problem, not a handshake one
• SSL certificates — how DomainDash checks SSL