Certificates2026-03-27

OpenSSL Verify Certificate Chain: Root, Intermediate, Leaf

Verify a local certificate chain or a live TLS server with OpenSSL, identify missing intermediates, and understand the trusted-root versus untrusted-chain options.

sslcertificatetlschainopensslpki

Verify an SSL certificate chain with OpenSSL

A TLS certificate chain connects a leaf certificate for a hostname through one or more intermediate CA certificates to a trusted root. The server normally sends the leaf and intermediates. The client decides which roots it trusts. A certificate can be within its date range yet fail because an intermediate is missing, a root is untrusted, or the hostname does not match.

Trusted root CA (client trust store)
  └─ Intermediate CA (normally sent by server)
       └─ Leaf certificate for example.com (sent by server)

Verify separate local files

Suppose you have leaf.pem, intermediate.pem, and a root you deliberately trust as root.pem. Run:

openssl verify -CAfile root.pem -untrusted intermediate.pem \
  -verify_hostname example.com -show_chain leaf.pem

Expected success begins with leaf.pem: OK; -show_chain also prints the path OpenSSL built. -CAfile supplies a trust anchor. -untrusted supplies a candidate intermediate, which must itself chain to that trusted root. Do not put an arbitrary downloaded intermediate into -CAfile merely to make a failing check pass: that changes what you trust. Replace example.com with the actual hostname; without -verify_hostname, openssl verify checks the chain but does not assert that a particular DNS name matches.

If you have two intermediates, concatenate them in issuer order into intermediates.pem and pass that file to -untrusted. For a publicly issued certificate, you may use your machine's configured CA store instead of a supplied root.pem; the store location varies by OS and OpenSSL build. These examples use OpenSSL 3. The older LibreSSL bundled with some macOS versions lacks -show_chain and -verify_hostname; use OpenSSL 3 for the command as written. The openssl verify manual explains these options.

Check a live server

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

-servername sends SNI so a shared server can select the right certificate. -showcerts displays the certificates it sent. -verify_return_error makes certificate validation errors stop the handshake instead of continuing for diagnostics. Check the final verification result and certificate list: a successful chain on your machine does not guarantee every client trusts the same root. The s_client manual documents these flags.

Do not diagnose the chain only by counting certificates. Some deployments have more than one intermediate, and a client might already have a missing intermediate cached. What matters is whether the intended clients can build a valid path to their trusted root.

Fix common failures

Symptom Likely next check
unable to get local issuer certificate Is the issuing intermediate missing from the server's chain or your -untrusted file? Is the intended root trusted?
self-signed certificate in certificate chain Are you using a private CA? Install its root in the relevant client trust store only if it is your trusted CA.
hostname mismatch Check the leaf certificate's Subject Alternative Names and the exact SNI/hostname used.
certificate has expired Renew or replace the expired certificate; adding intermediates will not fix the date.

If your CA gave you a leaf and intermediate PEM file, a common server-chain file puts the leaf first, then intermediate(s):

cat leaf.pem intermediate.pem > fullchain.pem

Configure the server with the full-chain file and its matching private key, using that server's current instructions, then rerun the live check. The root generally remains in the client's trust store rather than in the served chain. Never publish your private key while assembling certificate files.

The SSL Checker makes a live TLS connection and reports Node.js trust status, validity dates, and certificate fields for a hostname. The SSL Decoder helps inspect a PEM certificate's issuer, subject, and SANs. Neither replaces verification against the exact trust store and policy of every client you support. For PEM, CRT, DER, and PFX differences, see Certificate Formats Explained.