SSL handshake failed
A generic error that means the TLS handshake between the client and your server didn't complete. Usually one of four root causes; mostly fixable.
"SSL handshake failed" is the catch-all error browsers and clients show when something in the TLS handshake didn't work. It's not very specific by itself; the actual cause is usually one of four things.
The four most common causes
1. Certificate name mismatch. Client connected to acme.com, server presented a cert for yourapp.com. Browser refuses to trust it.
How to check: openssl s_client -servername acme.com -connect <edge>:443 and read the cert. Does the Subject or any SAN entry include acme.com?
Fix: make sure your edge is serving the correct cert based on the SNI in the ClientHello. For multi-tenant SaaS, this means your cert lookup by hostname is broken.
2. Expired certificate. Cert was valid yesterday, expired overnight.
How to check: openssl s_client -showcerts -servername acme.com -connect <edge>:443 | openssl x509 -noout -dates
Fix: renew the cert. Investigate why your auto-renewal didn't fire (rate limit, DNS challenge failure, etc.).
3. Untrusted CA. The cert is signed by a CA the browser doesn't trust. Most common cause: self-signed cert in production.
How to check: same openssl command; look at the Issuer line. Is it a real CA (Let's Encrypt, DigiCert) or your own internal CA?
Fix: get a real cert from a public CA.
4. Cipher mismatch. Client only supports old TLS versions or ciphers your server has disabled. Rare in 2026 but happens with legacy embedded devices.
How to check: nmap --script ssl-enum-ciphers -p 443 <edge>
Fix: usually you don't — disabling TLS 1.0/1.1 is correct. Tell the client to upgrade.
When you can't even handshake
If the connection drops before the certificate is even presented:
- Firewall is blocking port 443.
- Your server isn't actually listening on 443.
- SNI routing is misconfigured and the edge doesn't know what cert to serve.
Run curl -v https://acme.com and read the verbose output.