What is the methodical order for diagnosing a TLS handshake that fails for some clients only?

What is the methodical order for diagnosing a TLS handshake that fails for some clients only?

A handshake involves ClientHello, ServerHello, certificate, key exchange, and Finished. 'Works here, fails there' means a negotiation mismatch hidden in those messages. Diagnostic playbook, top down.

— Capture the failing ClientHello: a packet capture or openssl s_client -connect host:443 -servername host from the affected client class reveals offered versions, cipher suites, and SNI.
— Check SNI first: a client not sending Server Name Indication on a multi-tenant IP gets the wrong default cert. Old clients and some libraries omit it.
— Compare offered versions: a client capped at TLS 1.2 against a server set to 1.3-only fails at hello, not at the certificate.
— Inspect signature_algorithms and supported_groups: an ECDSA-only server config with an RSA-only client produces a no-shared-cipher alert.
— Read the alert code returned (handshake_failure 40, protocol_version 70, unrecognized_name 112); it names the layer that failed.

Evidence vs. speculation: the TLS alert number is a precise diagnosis; guessing from the error message text is not.

Further reading: RFC 8446 sections 4.1.2 and 6 (alert protocol); RFC 6066 for SNI.

Bottom line: capture the ClientHello and read the alert code; the mismatch is always named in the handshake itself.