TLS Certificate Chain Problems: Diagnosing with OpenSSL

"Certificate error" is a symptom, not a diagnosis. The certificate may be expired, the chain may be missing an intermediate, the client may be sending the wrong SNI, or the server may be presenting a chain that only validates on the machine you tested from. OpenSSL's s_client answers all of those in one command, which is why it is still the first tool to reach for.

Fetch and Verify in One Step

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

Read three things in the output: the Verify return code line, the chain that is printed after Certificate chain, and the negotiated protocol and cipher. A verify code of 0 (ok) means the chain validated against your local trust store - nothing more. unable to get local issuer certificate means the server did not send an intermediate the client needs, or your trust store lacks the root.

Common Failures and What They Mean

• unable to get local issuer certificate - missing intermediate in the server's chain (the classic misconfiguration: server sends leaf plus root, or leaf only).
• certificate has expired / not yet valid - check the validity window with openssl x509 -noout -dates -in cert.pem and confirm the clock on both endpoints. A wrong system clock produces exactly the same error as an expired certificate.
• hostname mismatch - the requested name is not in the subject alternative names. CN-only certificates are no longer sufficient for browsers.
• self-signed certificate in chain - an internal CA is in use and the client has no trust anchor for it; correct for lab systems, wrong for anything public.

Inspect a Certificate File Locally

openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName
openssl rsa -in server.key -check
openssl x509 -noout -modulus -in server.crt | openssl md5
openssl rsa  -noout -modulus -in server.key | openssl md5
openssl verify -CAfile ca-bundle.pem -untrusted intermediate.pem server.crt

The modulus comparison is the fastest way to answer "does this key match this certificate?" - the two MD5 values must be identical. openssl verify with -untrusted lets you test the exact chain a server should be sending, before you change anything in production.

Chains on Network Infrastructure

Management planes hit the same problems: web UIs, NETCONF/RESTCONF APIs and SNMPv3-to-TLS gateways all depend on a chain the client trusts. Internal CAs are normal here - the requirement is to distribute the root deliberately rather than disabling verification. Where certificates are provisioned across device fleets, automate the renewal and the trust-store distribution; the API-based approaches are described in NETCONF, RESTCONF and gNMI compared, and out-of-band management interfaces (which frequently carry their own self-signed certificate) in iDRAC versus iLO versus IPMI. If your TLS endpoint is a DNS service, the zone and DNSSEC side is in BIND 9 authoritative zone configuration.

原文链接：https://www.openssl.org/docs/manmaster/man1/openssl-s_client.html