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 marks the SSL check as Down 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 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, a cipher suite, and exchange certificates. If any step fails before certificate validation, you get tls_error. The handshake failing means the client and server couldn't agree on how to talk, which is usually a configuration issue on the server.

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 — symptoms look identical to a config issue.
• You disabled TLS entirely. The server is serving plain HTTP on port 443 (yes, this happens).

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. Click "Check now" in DomainDash. Status should flip to Healthy.

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
• SSL certificates — how DomainDash checks SSL