Verify TLS certificates from the command line

Use openssl verify to validate a certificate chain. For a TLS server, also specify the expected hostname and server purpose. Supply intermediate certificates with -untrusted and trusted roots with -CAfile or the trust configuration appropriate to your OpenSSL installation.

An OK result means the checks you enabled passed. It does not automatically prove that the certificate is unrevoked, that its private key matches, or that every browser will accept it.

Verify a local certificate

A basic chain check uses the configured trust sources:

openssl verify cert.pem

For an HTTPS server certificate, make the intended checks explicit:

openssl verify -purpose sslserver -verify_hostname example.com cert.pem

If the CA supplied intermediate certificates separately:

openssl verify -purpose sslserver -verify_hostname example.com \
  -untrusted ca-chain.pem cert.pem

-untrusted makes those certificates available for chain building without turning them into trust anchors.

For a private CA:

openssl verify -purpose sslserver -verify_hostname example.com \
  -CAfile my-root-ca.pem -untrusted ca-chain.pem cert.pem

An OpenSSL-style hashed directory can be supplied with -CApath /etc/ssl/certs. Default trust paths depend on how OpenSSL was built and installed; they may differ from the browser's or application's trust sources. See openssl verify and its verification options.

Verify a live endpoint

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

-servername sends SNI so the server selects the intended virtual host. -verify_hostname performs the name check. -verify_return_error stops the handshake when certificate verification fails; without it, s_client is a diagnostic tool that can continue after verification errors.

Keep standard error visible and inspect the command's status. Revocation checks require an appropriate CRL or OCSP workflow; a default successful connection is not a revocation check.

Once the configuration is correct, monitor the certificate actually served by each endpoint. Guance SSL tests support hostname/port checks and remaining-lifetime conditions. Run a test first, then choose a schedule and alert threshold around your renewal process. The result describes the endpoint observed from that test location, not every possible client's trust policy.

Interpret common verification errors

A code narrows the failure; it does not uniquely identify a repair. Read the depth and certificate details in the diagnostic output.

Common questions

Why does a browser work when OpenSSL fails?

They may use different trust stores, cached intermediates, chain-building behavior, or policies. Diagnose against the client you need to support rather than assuming one tool is universally authoritative.

Does OK prove the private key matches?

No. Compare the certificate's public key with the private key's public component in the same encoding, and only compare hashes after both extraction commands succeed.

How do I verify a PFX or P12 archive?

Export the certificate without the private key:

openssl pkcs12 -in cert.pfx -clcerts -nokeys -out cert.pem

Extract any required CA certificates separately and use them as untrusted intermediates as appropriate. Do not blindly trust everything in an archive, and do not export private keys merely to validate certificates.