Checking TLS certificates from the command line

When a site throws a certificate warning, the browser tells you something is wrong but not much about what. A couple of commands get you the details in a few seconds.

See what the server actually sends

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

This prints who the certificate was issued to, who signed it, when it expires and every name it covers. The -servername flag matters: without it, a server that hosts several sites may hand back the wrong certificate, and you end up chasing a problem that isn't there.

Check the chain

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

Look for Verify return code: 0 (ok) near the end. The most common failure I see is a server that sends its own certificate but not the intermediate. Desktop browsers often paper over that by fetching the missing piece themselves, so the site looks fine on a laptop and fails on phones, scripts and monitoring tools.

Just the expiry date

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -enddate

That one line is worth dropping into a monitoring check. Automated renewals are reliable right up until the day they quietly stop.

What usually turns out to be wrong

• The name you typed isn't in the certificate's subject alternative names.
• The intermediate certificate is missing from the server's chain.
• The certificate expired, or the client's clock is wrong.
• Something in the middle, such as a proxy or inspection device, is presenting its own certificate.

Most certificate problems are one of those four.