SSL Certificate Debugging with openssl s_client

Luke Hebert

- 3 minutes read - 446 words

When a TLS handshake fails or a certificate chain looks off, openssl s_client is the fastest way to see exactly what the server is sending and whether your trust store actually validates it. The commands below cover the most common debugging scenarios: dumping the full chain, verifying against a specific CA, extracting metadata, and confirming that a key, certificate, and CSR all belong to the same identity.

Show All Certificates Sent by the Server

This displays the full chain (leaf, intermediate, and root) that the server presents during the handshake.

openssl s_client -showcerts -connect <fqdn>:<port>

Verify Certificates Against a CA Certificate (PEM File)

Point openssl at your root or intermediate PEM file to confirm the chain validates correctly.

openssl s_client -CAfile /opt/cloudera/security/CAcerts/root.pem -showcerts -connect <fqdn>:<port>

Dump Certificate and Metadata

Pipe the handshake output into openssl x509 to get a human-readable dump of the leaf certificate, including subject, issuer, extensions, and validity period.

echo | openssl s_client -connect master-1.lab.atx.example.com:50470 2>/dev/null | openssl x509 -noout -text

Test Certificates Using Keytool

Useful when your trust store lives in a Java keystore (JKS). The process substitution feeds the PEM output of keytool directly into openssl.

openssl s_client -verify 100 -showcerts \
  -CAfile <(keytool -list -rfc -keystore /opt/cloudera/security/jks/truststore.jks -storepass <password>) \
  -connect keytrustee_kms_host:16000

Dump Specific Certificate Metadata (Expiration and CN)

A quick one-liner to grab just the subject and validity dates without the full text dump.

echo | openssl s_client -connect master-1.lab.atx.example.com:50470 2>/dev/null | openssl x509 -noout -subject -dates

Verify That Certificate, Key, and CSR Match

Each of these commands prints the SHA-256 fingerprint of the public key. All three hashes must be identical for the key, certificate, and CSR to belong to the same identity.

openssl pkey -in privateKey.key -pubout -outform pem | sha256sum
openssl x509 -in certificate.crt -pubkey -noout -outform pem | sha256sum
openssl req -in CSR.csr -pubkey -noout -outform pem | sha256sum
Important

If the three hashes differ, the private key does not correspond to the certificate or CSR. Re-issue the CSR from the same key pair before deploying.

Known Issue: S3 Guard with HSM

There is a documented case where S3 Guard combined with an HSM-backed key store causes unexpected chain-validation failures. See the support case for details: https://csh.example.com/ccs/index.html#/case/222524/case-details.

Tips for Faster Debugging

  • Add -tls1_2 or -tls1_3 to force a specific protocol version when the server negotiates unexpectedly.
  • Use -servername <fqdn> to send the correct SNI value, especially behind load balancers.
  • Combine -showcerts with -CAfile to see both the chain and the verification result in one pass.
  • If you only need the leaf cert in PEM form, append | openssl x509 -out leaf.pem to any of the echo | pipelines above.