
When you visit an https:// website, your browser and the server go through a brief negotiation process before any data is exchanged. This is the SSL/TLS handshake — where both sides agree on encryption settings, verify certificates, and establish a secure channel.
If anything goes wrong during this process, you get an SSL handshake failure. The connection can't be established, and the browser shows an error.
In simple terms:
A failure at any of these steps causes the handshake to fail.
The most frequent cause. If your SSL certificate has passed its expiry date, browsers will refuse to complete the handshake.
Check your certificate expiry date:
echo | openssl s_client -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -dates
If it's expired, renew it immediately. Setting up SSL certificate monitoring means you'll get an alert weeks before expiry, not after it's already broken things.
Your server might only support older TLS versions (like TLS 1.0 or 1.1) that modern browsers have dropped support for. Or conversely, a very old client trying to connect to a server that only accepts TLS 1.3.
Check what versions your server supports:
nmap --script ssl-enum-ciphers -p 443 yourdomain.com
Modern best practice is to support TLS 1.2 and TLS 1.3. Disable TLS 1.0 and 1.1 — they have known vulnerabilities.
In Nginx:
ssl_protocols TLSv1.2 TLSv1.3;
The certificate is issued for one domain but being served for another. This happens when:
www.example.com but someone visits example.com (or vice versa)Check the certificate's Common Name and Subject Alternative Names:
echo | openssl s_client -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName
An SSL certificate needs to be accompanied by any intermediate certificates that link it back to a trusted root CA. If intermediate certs are missing, some clients (especially on mobile or non-updated systems) can't verify the chain and the handshake fails.
Test your certificate chain at SSL Labs.
If the server and client share no common cipher suites, they can't agree on how to encrypt the connection. This is rare with modern configurations but can happen on highly restricted servers or very old clients.
SSL certificates are time-sensitive. If the client's system clock is significantly wrong (more than a few minutes), certificate validity checks fail even on a perfectly valid certificate. This is a client-side issue.
On macOS/Linux: timedatectl status. Enable NTP sync if it's drifting.
A firewall — on your server or a network device in between — might be blocking or interfering with HTTPS traffic. Test from outside your network.
OpenSSL's command-line tool gives you a detailed view of what's failing:
openssl s_client -connect yourdomain.com:443 -tls1_2
openssl s_client -connect yourdomain.com:443 -tls1_3
Look for the specific error message in the output — it will usually name the exact failure point.
For a simpler check, SSL Labs' free SSL test gives you a full analysis of your certificate, chain, protocols, and cipher suites in one report.
The best way to avoid SSL-related downtime is to monitor your certificates proactively. Domain Monitor monitors your SSL certificates and alerts you before they expire, so you never have an unexpected handshake failure on a live site.
Read more about how SSL certificates work and the different types of SSL certificates available.
A subdomain takeover lets an attacker claim your subdomain by exploiting dangling DNS records. Learn how it happens, real-world examples, and how DNS monitoring detects it.
Read moreMean time to detect (MTTD) measures how long it takes to discover an incident after it starts. Reducing MTTD is one of the highest-leverage improvements in reliability engineering.
Read moreBlack box monitoring tests your systems from the outside, the way users experience them — without access to internal code or infrastructure. Learn how it works and when to use it.
Read moreLooking to monitor your website and domains? Join our platform and start today.