SSL Handshake Errors: Fixing Handshake Failures

What happens in the handshake

When a visitor opens https://www.example.co.uk/, their browser and your server run through a short negotiation before any page is requested:

1. The browser says which TLS versions and encryption methods it supports, and which hostname it wants. Sending the hostname at this stage is called SNI, and it is how one server with one IP address can hold certificates for many sites.
2. The server picks a version and method, and sends its certificate plus any intermediate certificates that link it to a trusted authority.
3. The browser checks the certificate: is it in date, does it name this hostname, and does the chain lead to a root authority the browser already trusts?
4. If everything checks out, both sides set up encryption and the ordinary HTTP request begins.

A failure at step 2 or 3 means there is no HTTP response at all, which is why an audit reports an SSL error rather than a status code. It also means one bad certificate breaks every page on that hostname at the same moment.

Reading the error message

Browsers name the specific check that failed. The name is the most useful clue you have, so copy it exactly before doing anything else.

Behind Cloudflare there are two more to know. Error 525 means Cloudflare could not complete a handshake with your origin server, and error 526 means the origin's certificate was not valid when Cloudflare's SSL mode is set to check it strictly. In both cases visitors' browsers are fine; the problem is between Cloudflare and your server.

Testing the certificate from the command line

Browsers cache intermediate certificates and sometimes fetch missing ones on their own, so a site can look fine in your browser while failing for crawlers, older phones and command-line tools. openssl shows exactly what the server sends.

# What does the server send for this hostname? Always include -servername.
openssl s_client -connect www.example.co.uk:443 -servername www.example.co.uk -showcerts </dev/null

# Expiry dates, subject and the hostnames the certificate covers
openssl s_client -connect www.example.co.uk:443 -servername www.example.co.uk </dev/null 2>/dev/null \
  | openssl x509 -noout -dates -subject -issuer -ext subjectAltName

# Does a normal client accept it? curl fails loudly on chain and name problems
curl -sv -o /dev/null https://www.example.co.uk/ 2>&1 | grep -iE "SSL|certificate|subject|expire"

What to look for in the output:

• notAfter is the expiry date. If it is in the past, the certificate needs renewing, and if it is within a few days, renewal has probably stopped working.
• subjectAltName lists every hostname the certificate covers. Browsers ignore the older common name field, so the hostname must be here.
• The chain. -showcerts prints each certificate the server sends. A publicly issued certificate normally comes with at least one intermediate. If only one certificate appears, the chain is incomplete.
• Verify return code at the end should be 0 (ok). A code such as 21, "unable to verify the first certificate", confirms a missing intermediate.

Expired certificates and failed renewals

Most expiry problems are really renewal problems. Free certificates from Let's Encrypt last 90 days and are meant to renew automatically, and the maximum lifetime of all publicly trusted certificates is being reduced in stages under CA/Browser Forum rules, starting in 2026. Manual renewal is becoming impractical, so the aim is a renewal process that works on its own and tells you when it does not.

Common reasons automatic renewal stops:

• The validation request cannot reach the server. Let's Encrypt's HTTP check fetches a file under /.well-known/acme-challenge/. A firewall, a country block, a deny rule for dotfolders or a maintenance page can all stop it.
• DNS points somewhere else. After a server move, an old AAAA (IPv6) record often still points at the previous server. The certificate authority may try IPv6 first and fail even though IPv4 is correct.
• The renewal job is not running. Check that the certbot timer or cron job exists and look at its log, usually under /var/log/letsencrypt/.
• The new certificate was issued but not loaded. The web server needs a reload after renewal. Without one it keeps serving the old certificate from memory until it expires.
• Nobody was told. Let's Encrypt stopped sending expiry reminder emails in 2025, so do not rely on them. Use your own monitoring.

# Certbot: list certificates and their expiry, then rehearse a renewal
sudo certbot certificates
sudo certbot renew --dry-run
# After a real renewal, reload the web server so it uses the new files
sudo systemctl reload nginx

If only one visitor sees a date error while everyone else is fine, check that visitor's device clock. A clock set months out causes a date error on every HTTPS site they visit.

Hostname mismatches

A certificate covers exactly the names listed in its subject alternative names, and nothing else. The most frequent gaps are:

• www and the bare domain. A certificate for www.example.co.uk does not cover example.co.uk. Even if the bare domain only redirects to www, the redirect happens after the handshake, so the bare domain needs its own name on the certificate.
• Wildcards cover one level only. *.example.co.uk covers shop.example.co.uk but not example.co.uk itself and not eu.shop.example.co.uk.
• Extra domains on the same site. Old brand names, .com versions and parked domains that redirect to the main site all need valid certificates if anyone ever visits them over HTTPS.
• The wrong virtual host. If a hostname has no HTTPS configuration of its own, the server answers with its default certificate, which belongs to another site. The fix is to add the hostname to the correct site, not to change the default.

# Issue one certificate covering both names with certbot and nginx
sudo certbot --nginx -d example.co.uk -d www.example.co.uk

Once both names have a valid certificate, redirect one to the other with a single 301. Redirect order and HTTPS redirects are covered in the HTTPS redirects guide.

Incomplete certificate chains

Your certificate is signed by an intermediate certificate, which is signed by a root that browsers trust. The server must send your certificate and the intermediates; the root is already on the visitor's device. If the intermediate is missing, desktop browsers that have seen it before may cope, while crawlers, API clients, some Android devices and command-line tools fail with an unknown issuer error. This is one of the most common reasons an audit reports an SSL error that you cannot reproduce in your own browser.

The fix is to point the server at the full chain file rather than the certificate on its own:

# nginx
ssl_certificate     /etc/letsencrypt/live/example.co.uk/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.co.uk/privkey.pem;

# Apache 2.4.8 and later
SSLCertificateFile    /etc/letsencrypt/live/example.co.uk/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.co.uk/privkey.pem

With a certificate bought from a commercial authority, you usually receive your certificate and a separate bundle of intermediates. For nginx, join them into one file with your certificate first and the intermediates after it. Hosting panels usually have a separate field for the intermediate or CA bundle; make sure it is filled in.

Protocol and cipher mismatches

TLS 1.0 and 1.1 are formally deprecated and current browsers refuse them. A server that only offers those versions, or only very old ciphers, produces a version or cipher mismatch error in every modern browser. The opposite problem also happens: a server locked down to TLS 1.3 only can refuse older but still reasonable clients, including some crawlers and business systems.

A sensible setting for most public sites in 2026 is TLS 1.2 and TLS 1.3 enabled, with nothing older:

# nginx
ssl_protocols TLSv1.2 TLSv1.3;

# Apache
SSLProtocol -all +TLSv1.2 +TLSv1.3

# Check which versions the server accepts
openssl s_client -connect www.example.co.uk:443 -servername www.example.co.uk -tls1_2 </dev/null
openssl s_client -connect www.example.co.uk:443 -servername www.example.co.uk -tls1_3 </dev/null

An ERR_SSL_PROTOCOL_ERROR with no certificate at all often means port 443 is answering with plain HTTP, usually because the ssl parameter is missing from an nginx listen 443 line, or a load balancer is forwarding to the wrong port.

Behind a CDN

With Cloudflare or a similar CDN, there are two connections: visitor to CDN, and CDN to your server. Use a mode that encrypts and validates the second connection, called Full (strict) in Cloudflare, and give your origin a valid certificate, either a public one or the CDN's own origin certificate. A 525 means the origin handshake failed; check that the origin listens on 443 with TLS and accepts TLS 1.2 or later. A 526 means the origin certificate is expired, self-signed or for the wrong name.

The fix, step by step

Keeping certificates healthy

• Automate renewal everywhere. Every hostname that serves HTTPS should renew automatically, including redirect-only domains and subdomains used for email links or campaigns.
• Monitor expiry independently. Use an external check that warns you well before expiry, rather than relying on your certificate authority or host to email you.
• Reload after renewal. Make sure the renewal process reloads the web server, for example with a certbot deploy hook.
• Keep the challenge path open. When adding firewall rules, maintenance pages or dotfolder blocks, leave /.well-known/ reachable.
• Tidy DNS after moves. Remove or update A and AAAA records that point at old servers.
• Fix mixed content too. Once the certificate is sound, pages that load images or scripts over plain HTTP still show warnings; the mixed content guide covers that separately.