TLS Handshake Failed: Find the Certificate or Protocol Fault

Start with the certificate.

An expired, untrusted, mismatched, or not-yet-valid certificate causes many failures, so check the hostname and system clock before changing protocols, cipher suites, or application settings.

The visible message varies by client. Chrome may show NET::ERR_CERT_DATE_INVALID or NET::ERR_CERT_COMMON_NAME_INVALID. curl returns error 60 for a peer certificate that cannot be authenticated, while OpenSSL prints details such as certificate has expired or unable to get local issuer certificate. The documented libcurl error codes↗ distinguish certificate rejection from connection and protocol failures.

Check these in order:

1. Confirm the device has the correct date, time, and time zone.
2. Verify that the requested hostname appears in the certificate Subject Alternative Name field.
3. Inspect the certificate's Not Before and Not After dates.
4. Check that the server sends required intermediate certificates.
5. Confirm that the root certificate is trusted by the client operating system or application.

Run OpenSSL against the real hostname, retaining -servername because virtual hosts use Server Name Indication to select the certificate:

Look at Verify return code, the negotiated protocol, and the certificate chain. A return code of 0 means OpenSSL accepted the chain under its current trust configuration; it does not prove that every browser, embedded client, or Java runtime has the same trusted roots.

Do not use curl -k, --insecure, or disabled certificate verification as a fix. Those options suppress authentication and convert a useful security failure into a connection vulnerable to interception.

Both peers must agree.

The client offers supported versions and cryptographic parameters, the server selects compatible options and presents its identity, and the peers derive session keys before protected application data can cross the connection.

For TLS 1.3, the simplified sequence is ClientHello, ServerHello, encrypted server authentication messages, Finished messages, and application data. The exact exchange includes extensions such as supported_versions, key_share, signature_algorithms, and Server Name Indication; the TLS 1.3 standard↗ defines the messages and alert codes.

A failure immediately after ClientHello usually points toward an unsupported protocol, absent shared cipher or signature algorithm, malformed extension, blocked Server Name Indication, or a middlebox that dislikes the offered traffic. A failure after the server certificate arrives more often indicates trust, hostname, expiry, revocation, or client-certificate authentication trouble.

Legacy clients are the awkward case. A device limited to TLS 1.0 or obsolete cipher suites may reach the server over TCP but still receive protocol_version, handshake_failure, or an abrupt reset from a modern endpoint. Re-enabling obsolete protocols on a public server is usually the wrong repair; update or replace the client, or isolate a compatibility endpoint with strict access controls.

Find the last message.

Capture traffic at the failing client, apply a narrow display filter, and identify whether the conversation ends before ServerHello, during certificate authentication, or with a TLS alert from either endpoint.

Start with tcp.port == 443 && ip.addr == 203.0.113.10, replacing the address with the server involved. If the service uses another port, filter that port instead. The broader tls.handshake || tls.alert filter exposes decoded handshake records and alerts; Wireshark maintains the available TLS display-filter fields↗.

Interpret the packet sequence rather than treating every red or black row as the cause:

• ClientHello followed by repeated TCP retransmissions means the server, firewall, route, or middlebox did not return a usable response.
• ClientHello followed by a TCP reset suggests a listener, proxy, intrusion-prevention rule, or incompatible endpoint closed the connection.
• A fatal protocol_version alert identifies a version mismatch.
• A fatal handshake_failure alert is less precise and can mean no shared cipher, signature mismatch, missing client authentication, or a server policy rejection.
• ServerHello and Certificate followed by a client alert move suspicion toward certificate validation.

TLS 1.3 encrypts most handshake messages after ServerHello, so a capture without session secrets cannot expose every detail. Browser key logging through SSLKEYLOGFILE can permit decryption in controlled debugging environments, but it records sensitive session secrets and should never be left enabled on a shared or production machine.

Change one path.

Test the same hostname from another network and the same client against another trusted site, because those two comparisons separate an endpoint configuration failure from local proxy, firewall, DNS, or connectivity trouble.

Use the hostname, not merely the IP address. TLS virtual hosting depends on Server Name Indication, while HTTPS certificate verification checks names rather than assuming every address belongs to one service. openssl s_client should therefore include -servername, and curl should normally receive the original URL.

A corporate TLS inspection proxy can issue a substitute certificate signed by an internal root. If that root is installed in the operating system but absent from Firefox, Java, Python, a container image, or an embedded application, browsers may connect while another client reports unknown ca, self signed certificate in certificate chain, or CERTIFICATE_VERIFY_FAILED.

Try these comparisons:

1. Repeat the request on a mobile hotspot, without the corporate VPN or proxy.
2. Resolve the hostname from both networks and compare the returned address.
3. Inspect the certificate issuer on each path.
4. Check whether direct TCP access to the service port succeeds.
5. Ask the network owner whether outbound TLS inspection or protocol filtering is active.

Do not assume a successful TCP health check proves HTTPS works. A load balancer can accept the connection while the TLS listener has the wrong certificate, unsupported settings, or no healthy backend. Conversely, repeated failures across unrelated networks and current clients usually belong to the server operator, not the user's browser.

Correct the clock first.

On an iPhone, enable automatic date and time, remove untrusted VPN or filtering profiles, switch networks, and update iOS before resetting network settings or blaming the destination server.

Open Settings > General > Date & Time and enable Set Automatically. A clock outside the certificate validity period can produce “A TLS error caused the secure connection to fail” even though the site and network are otherwise working.

Next, compare Wi-Fi with cellular service. If cellular works, disable any VPN, DNS filter, parental-control profile, or HTTPS inspection product associated with that Wi-Fi connection. Settings > General > VPN & Device Management shows installed configuration profiles, but a managed work or school profile should be removed only by its administrator.

If every current device fails on the same site, the iPhone is probably innocent. If only an old iPhone fails and the server requires newer TLS versions or signature algorithms, update iOS; when the model can no longer receive a compatible security release, replacement is safer than weakening the server for one obsolete client.