Diagnose protocol and key failures

Not every TLS failure is about certificates. A handshake can fail before certificate verification even starts, when the two peers cannot agree on a protocol version or algorithm. And a server can fail to start at all when its key does not match the certificate. These three problems produce very different errors, and telling them apart saves you from debugging the wrong layer.

No shared protocol

An old client that only speaks TLS 1.0 cannot talk to a server that requires TLS 1.2 or newer. The handshake dies immediately, before any certificate is exchanged. You can reproduce the shape of this by forcing a version during a controlled test:

openssl s_client -tls1_2 -connect example.org:443 -servername example.org </dev/null

Compare with -tls1_3 where supported. Against a server that refuses the version you forced, the output contains no Certificate chain section at all — just an alert like tlsv1 alert protocol version or a no protocols available error. That absence is the clue: if you never received a certificate, stop staring at certificate fields.

Key does not match certificate

The other failure lives on the server. After a renewal or a copy-paste deployment, the certificate on disk and the private key on disk can come from different generations. Node refuses to start with a key-mismatch error; nginx says SSL_CTX_use_PrivateKey_file ... key values mismatch.

You confirm it without exposing secrets. A key pair matches when both files contain the same public key, so for a key pair, compare public-key fingerprints rather than exposing private material:

openssl x509 -in app.crt -noout -pubkey | openssl sha256
# SHA2-256(stdin)= 7f3c9e...
openssl pkey -in app.key -pubout | openssl sha256
# SHA2-256(stdin)= 7f3c9e...

The first command extracts the public key from the certificate, the second derives it from the private key. Identical hashes mean the pair belongs together. Different hashes mean you deployed mismatched files — find the key that was generated with this certificate’s CSR.

The tempting wrong fix

When an ancient device cannot connect, someone will suggest re-enabling TLS 1.0 on the server. Do not enable obsolete protocols just to satisfy an abandoned client — that downgrades every connection’s floor, not just one client’s. Upgrade or isolate the dependency instead, for example behind a dedicated proxy that only that client uses, while the main endpoint keeps a modern minimum.