What is a TLS handshake?

The TLS handshake is the negotiation that happens before any HTTPS request: client and server agree on a protocol version and cipher, exchange the key material for an encrypted session, and — the part certificate work cares about — the server presents its certificate chain for the client to validate. Every certificate error a user ever sees is raised during this exchange.

In TLS 1.3 the sequence is one round trip. The client opens with supported versions, ciphers, and its key share, plus the server name (SNI) so a host serving many domains knows which certificate to present. The server answers with its own key share, the certificate chain, and a signed proof that it holds the certificate’s private key. The client then walks the chain to a trusted root, checks the hostname against the SAN list, checks validity dates, and only if everything holds does application data flow.

For debugging, the useful distinction is between failures of the handshake machinery and failures of certificate validation, because tools report them differently. A version or cipher mismatch (an old client meeting a TLS 1.3-only server, or the reverse) kills the connection before any certificate is seen — that is your ERR_SSL_VERSION_OR_CIPHER_MISMATCH class. Certificate problems — expired, wrong hostname, broken chain — happen after a successful negotiation, which is why a checker can simultaneously report "handshake succeeded" and "certificate invalid." Knowing which side of that line an error sits on halves the search space.

SNI deserves special mention as a silent failure source: a client that omits it, as some old libraries and health checks do, receives the server’s default certificate, which is often the wrong one. The resulting hostname mismatch looks like a certificate bug but is really a handshake configuration bug on the client.