“SSL handshake failed” means a client and server did not establish the secure connection needed for their next exchange. In modern systems that exchange is normally TLS, although browsers, libraries, and vendor error pages still use the older word “SSL.” The failure might be a TLS version or key-exchange mismatch, server-name or certificate problem, client-certificate requirement, or a rejection at an intervening proxy. The message alone does not identify which one. TLS 1.3 specifies the negotiation and authentication steps for establishing an authenticated connection for ordinary application traffic.
First identify the exact connection that failed: browser to CDN, CDN to origin, load balancer to application, or one service to another. Test from the same network and with the same hostname as the failing client where possible. Do not “fix” the symptom by disabling certificate verification, accepting an unknown certificate, or enabling obsolete TLS versions and ciphers.
Locate the failure before changing TLS settings
Write down the failing hostname, port, time with timezone, client or runtime, destination IP if known, and the precise error text. Note whether the issue affects one client, one host, one region, or all callers. A successful browser visit to a CDN hostname does not prove the CDN's separate origin connection works; likewise, a successful origin test does not prove the visitor-to-CDN hop works.
Separate the stages:
- Name resolution: “Could not resolve host” means the client did not obtain an address. No TLS handshake began. Check the hostname and the DNS answer observed by that client before investigating certificates.
- TCP connection: Connection refused, an unreachable address, or a TCP timeout can prevent TLS from starting. Verify the destination and network path; do not label every connection timeout a cipher mismatch.
- TLS negotiation and authentication: The peers exchange protocol versions, algorithms, server identity, and, where required, client credentials. A TLS alert, close, or local certificate-validation error can stop the connection before an HTTP request reaches the application.
- HTTP exchange: Once TLS succeeds, an HTTP 4xx or 5xx response is a different failure. The TLS result can be healthy even when the application returns an error.
The TLS 1.3 protocol overview places certificate authentication within the handshake. Some tools distinguish a cryptographic negotiation failure from a client rejecting the presented certificate, while others display both under a broad “handshake failed” message. Preserve the tool's exact diagnostic instead of reducing every case to “bad certificate.”
Test the same hostname with verification enabled
Use a known safe, unauthenticated GET endpoint for the first check. Replace the example hostname and route with the service under investigation:
curl --verbose --max-time 10 --output /dev/null 'https://app.example.com/health'
This is a read-only request only if that route's GET is safe by its application contract. --verbose reports connection and TLS progress; --max-time bounds the attempt. Curl verifies the peer certificate by default using its configured trust store. Run it from the affected host or equivalent network, because DNS, proxies, trust stores, and routing can differ by environment. Do not use this command with cookies, authorization headers, or a sensitive response unless its verbose output can be protected: curl may print request and response headers. The curl TLS certificate guide explains its trust checks, and the curl manual documents these options.
For a closer view of the TLS connection, OpenSSL 3.x offers a second read-only check. On Linux with GNU timeout, leave standard input connected while bounding the probe:
timeout 10s openssl s_client \
-connect app.example.com:443 \
-servername app.example.com \
-verify_hostname app.example.com \
-verify_return_error \
-brief
-servername sends the intended hostname through Server Name Indication (SNI); -verify_hostname checks the certificate identity; and -verify_return_error stops on a verification failure. That last flag matters: the OpenSSL s_client documentation says the test tool otherwise continues after certificate errors. -brief limits the output. Inspect the handshake and verification lines before the deadline; timeout can end an otherwise successful, still-open interactive session with a nonzero status, so its status alone is not a TLS verdict. On a system without GNU timeout, run s_client interactively and interrupt it after inspecting the handshake. Do not pipe immediate EOF into the probe: OpenSSL warns that this can close a TLS 1.3 connection prematurely. This command checks TLS, not an HTTP route. Its output does not prove that the application is healthy. Also, OpenSSL and curl may use different trust stores or proxy settings, so a difference between them is evidence to investigate, not proof that one tool is wrong.
Never use curl -k or OpenSSL options that suppress verification as a recommended repair. They can hide the identity failure you need to diagnose and expose the connection to interception. If a private CA is expected, confirm that the approved CA and intermediate chain are installed in the actual client's trust configuration, not that verification can be skipped.
Match the symptom to the TLS stage
Certificate name, chain, trust, or time
A certificate is useful only if the connecting client accepts its identity and chain. Check the hostname the client requested, the certificate's subject alternative names, issuer chain, validity dates, and the trust store used by that client. A server may present a valid certificate for the wrong virtual host when SNI is missing or incorrect. SNI exists to let a server select a name-specific TLS configuration, and OpenSSL's explicit -servername option prevents an IP-only test from accidentally testing a different site.
An expired certificate, incomplete intermediate chain, untrusted private CA, or wrong hostname calls for a precise certificate or trust-store change by the relevant owner. Check client and server clocks when a certificate appears not yet valid or expired, but do not assume clock skew from a generic handshake message. A certificate-validation problem may be client-specific: one OS image can lack a CA that another has.
If a service sits behind a CDN, inspect each certificate-bearing hop separately. For example, Cloudflare defines error 525 as a failed TLS handshake between Cloudflare and its origin under relevant SSL modes; its error 526 concerns origin-certificate validation in strict mode. Those are Cloudflare-specific diagnoses, not universal meanings of all handshake errors. Do not infer that an origin failure happened on the visitor's own TLS connection.
Protocol, cipher, SNI, and ALPN negotiation
The client and server need a compatible TLS version and cryptographic options. A recently restricted server policy can expose an old client runtime; a newly deployed client can expose an old server. Compare the exact affected client and server configurations, then decide whether the obsolete endpoint must be upgraded. Avoid expanding support to weak protocols merely to make a probe pass. The negotiated version and cipher shown by a successful OpenSSL test describe that test connection, not every client in the fleet.
SNI can affect which certificate or TLS policy a multi-tenant listener selects. Application-Layer Protocol Negotiation (ALPN) lets peers choose protocols such as HTTP/2 or HTTP/1.1 during TLS; an ALPN-related failure depends on the endpoint's policy, and an HTTP protocol error after TLS is not automatically a handshake failure. The ALPN specification defines that negotiation. Record what the failing client advertised before changing a server's policy. A generic s_client invocation may not advertise the same ALPN list as a browser or SDK, so compare like with like.
Mutual TLS and client certificates
In mutual TLS (mTLS), the server also authenticates the client. A missing client certificate, untrusted client CA, expired client certificate, or a certificate lacking the required usage can stop the exchange. Verify whether this listener actually requires mTLS, which CA it trusts, what certificate the client selects, and whether the client has permission to read its private key. Do not place a private key in a command line, diagnostic transcript, or support ticket. Test with an approved client configuration and inspect the server-side TLS/authentication error; the public OpenSSL probe above intentionally supplies no client credential and therefore may fail on a correctly configured mTLS endpoint.
Correlate the right logs and apply one targeted fix
At each TLS-terminating hop, inspect the listener's TLS error records and any handshake counters for the same time and destination. An application access log can be empty because the HTTP request never arrived. A client-side certificate validation failure might leave only client-side evidence; server logs alone cannot prove the client accepted the certificate. Keep logs and tickets limited to host, port, timestamp, TLS version or alert where available, SNI, and a safe connection ID. Avoid dumping private keys, full packet captures, credentials, or verbose authenticated request headers into a shared system.
The owner of the failing hop should make the smallest supported change: serve the right certificate and full chain for the requested name, restore a required SNI mapping, update an outdated client/runtime, configure approved mTLS credentials, or correct a proxy-to-origin TLS policy. Certificate replacement, trust-store changes, listener policy edits, and reloads change production state and require the normal approval and validation path. Retest the original failing client with verification still enabled, then check a previously working client so the fix does not break its path. If the operation crossed a CDN or proxy, test both visitor-to-edge and edge-to-origin evidence rather than a single URL.
For recurring failures, retain only the TLS-terminator and client events that your logging path actually captures. Fluxtail is a paid Starter/Pro logs-focused destination; search, filters, and Live Tail can help inspect delivered proxy or application records when useful fields have been emitted and mapped. It is not a TLS probe, certificate validator, or automatic handshake monitor. Missing application logs do not establish a successful TLS connection or a healthy origin. For a broader approach to interpreting the available evidence, see how to read logs.