Use openssl x509 with the noout and text options to print a certificate in readable form. Check four things first: the validity dates, the subject alternative names, the issuer, and the key type. Those fields explain most certificate outages and hostname errors.
Get the certificate
From a file:
openssl x509 -in cert.pem -noout -text
From a live server, passing the server name so you get the right certificate (see SNI):
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -text
Fields to read first
| Field | What to look for | Failure it explains |
|---|---|---|
| Validity (not before, not after) | Is today inside the window | Expiry outages, clock skew |
| Subject alternative name | Does the list include the hostname you use | Hostname mismatch |
| Issuer | Which CA signed it | Wrong chain, wrong environment such as staging |
| Public key | Type and size | Compatibility, policy checks |
| Basic constraints | CA flag false for a leaf | A CA certificate served as a leaf |
| Key usage | Server authentication allowed | Odd rejections by strict clients |
The names a certificate covers live in the subject alternative name extension, and modern clients check those, not the old common name. See hostname verification and SAN.
Shortcuts from the manual
The x509 command has options for each task:
# dates
openssl x509 -in cert.pem -noout -dates
# just the SAN extension
openssl x509 -in cert.pem -noout -ext subjectAltName
# will it still be valid in 30 days? (seconds)
openssl x509 -in cert.pem -noout -checkend 2592000
# does it match this host?
openssl x509 -in cert.pem -noout -checkhost app.example.com
The checkend option exits with a status that says whether the certificate will have expired after the given number of seconds, which makes it handy in scripts and CI. The checkhost option tests a name against the certificate.
Reading the dates correctly
The validity window is in UTC. A certificate that is not yet valid is as broken as an expired one, and it shows up when a server or client clock is wrong. If one machine rejects a certificate that others accept, compare system clocks before you suspect the certificate itself.
A quick routine
- Confirm dates and set an alert at a safe margin.
- Confirm the SAN list covers every name clients use.
- Confirm the issuer is production, not a test authority. See staging certificates.
- Confirm the whole chain with the showcerts option. See incomplete chains.
- Add the checkend test to a scheduled job. More ideas are in the expiry checklist.
Reading the extensions
Basic constraints should say CA is false on a normal server certificate. Extended key usage should list server authentication. A certificate that fails strict clients but passes lenient ones often has an unusual value in one of these. Print the text output once for a known good certificate and keep it as a reference to compare against.
Where Safeguard fits
Safeguard scans dependencies and SBOMs for known vulnerabilities, including those in the TLS and crypto libraries your projects pull in, and you can try it with the free scan at gold.safeguard.sh/scan.
Quick check
Why does the output show a different certificate than I expected?
You may have skipped the server name option, so the server sent its default certificate.
Which option prints just the dates?
The dates option on openssl x509, together with noout.
Sources
Last reviewed: 19 October 2026.
