OpenSSL Commands to Check TLS Certificates and Chains

Check a live HTTPS endpoint #

openssl s_client -connect example.com:443 -servername example.com \
  -verify_hostname example.com -verify_return_error -brief </dev/null

For a particular backend, keep the public hostname in both name options and replace only the connection address:

openssl s_client -connect 192.0.2.20:443 -servername example.com \
  -verify_hostname example.com -verify_return_error -brief </dev/null

This separates address selection from identity checking. The verification result depends on the trust anchors available to that OpenSSL installation. For a private PKI, supply the approved CA file with -CAfile company-ca.pem; do not replace verification with a blanket trust bypass.

Inspect a certificate file #

openssl x509 -in server.pem -noout -subject -issuer -dates

openssl x509 -in server.pem -noout -ext subjectAltName

openssl x509 -in server.pem -noout -fingerprint -sha256

openssl x509 -in server.pem -noout -checkend 604800

These commands inspect the subject, issuer, validity period, names and fingerprint. The final command checks whether the certificate expires within seven days. It is an expiry check, not a full trust or hostname check. A currently unexpired certificate can still have the wrong name or an untrusted issuer.

Examine what the server sends #

openssl s_client -connect example.com:443 -servername example.com \
  -showcerts </dev/null

The displayed list is the chain material supplied by the server, not a declaration that the chain is trusted. Compare the leaf's issuer with the supplied intermediates and the client's trust configuration. Browser success does not guarantee that a different client has the same trust store or chain-building behavior.

Common interpretation mistakes #

Do not treat a printed certificate as proof of successful validation. The strict test above uses -verify_return_error so verification errors stop the handshake rather than merely being reported. Check the system clock when validity dates appear wrong. If only one backend returns a different fingerprint, investigate deployment consistency before changing DNS or clients. Finally, a valid TLS identity does not prove the HTTP application is healthy; continue with an HTTP request after certificate verification succeeds.