Certificates & Site Ops · Field note
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.
Before you start
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 records the issuer name claimed by the certificate. Signature and path verification are still needed to confirm the relationship.
- Not Before / Not After tell you whether the inspection time is inside the certificate's declared validity window, not whether the certificate is trusted or otherwise valid for a deployment.
- 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.
- Key Usage and Extended Key Usage describe what the certificate key is intended to do, such as signing certificates or authenticating a TLS server.
- Basic Constraints distinguish an end-entity certificate from a CA certificate and may limit subordinate CA depth.
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 lists example.com and www.example.com, its recorded issuer is Let's Encrypt R11, and it has a short declared lifetime. Confirm the issuer relationship with signature and path verification.
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 the X.509 Certificate Parser to inspect validity, SANs, KU/EKU, constraints, SKI/AKI, signature algorithms, and both certificate and public-key fingerprints.
- Use the Certificate, Key & CSR Matcher when the question is whether a selected certificate contains the same public key as a CSR or key file.
- Use the CSR Decoder & Inspector to compare requested names with the names that were actually issued.
- Use the Certificate Chain Checker when several certificates must form one signature-verified path.
A certificate SHA-256 fingerprint identifies the complete certificate. An SPKI SHA-256 fingerprint identifies its public key. Two certificates can share the same SPKI fingerprint while having different issuers, names, serial numbers, or validity windows.
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.