How to Inspect an X.509 Certificate in Plain English
A practical way to read issuer, subject, SANs, validity, fingerprints, and signature details without getting lost in certificate jargon.
Tip
Inspect the current certificate, key, token, or endpoint output before changing deployment config; stale artifacts make fixes misleading.
Most certificate debugging does not start with ASN.1 theory. It starts with a practical question: does this certificate cover the hostname, is it still valid, who issued it, and is it the file I think it is?
The goal is to read the fields that change a deployment decision and ignore the rest until you actually need them.
Start with the fields that change decisions
- Subject Alternative Name (SAN) answers which hostnames the certificate covers.
- Issuer tells you which CA or intermediate signed it.
- Not Before / Not After tell you whether the certificate is currently valid.
- Subject is useful context, but SAN is the field modern hostname checks actually use.
- Fingerprint helps you compare two copies of what should be the same certificate.
Concrete certificate walk-through
Subject: CN=example.com
Issuer: C=US, O=Let's Encrypt, CN=R11
SAN: DNS:example.com, DNS:www.example.com
Valid: Not Before 2026-03-01, Not After 2026-05-30
That tells you four useful things quickly: the certificate is for example.com, it also covers www.example.com, it chains through Let's Encrypt, and it has a normal short lifetime.
Red flags worth checking first
- The hostname you need is missing from SAN.
Not Afteris already in the past or much closer than expected.- The issuer or signature algorithm does not match the environment you thought you deployed.
- The fingerprint differs between the file on disk and the certificate shown by the server.
Short tool handoff
- Use X.509 Certificate Parser to inspect the certificate fields in the browser without guessing where the important values live.
- Use PEM/DER Converter if the certificate is correct but packaged in the wrong encoding for the next system.
What readers still ask
Is the Common Name enough to check hostname coverage?
No. Treat SAN as authoritative for modern TLS checks. CN can still be present, but SAN is the field that matters most.
What if the certificate parses cleanly but the browser still warns?
Then the problem may be chain delivery, hostname coverage, trust store issues, or the live server presenting a different certificate than the file you inspected.
Developer workflow
Use this guide as an operations checklist before changing certificates, tokens, DNS, or deployment settings.
- Inspect the current artifact or endpoint output before making changes.
- Change one variable at a time so a failed verification has a narrow cause.
- Keep the rollback value, expiry, and verification command in the same runbook entry.
1. current deployed artifact
2. single config or key change
3. verify endpoint/client behavior
4. record rollback and expiry details