Clicking into a certificate's details in any browser shows a wall of fields that can look intimidating the first time. Here's what each one is actually telling you.
- Subject — who the certificate identifies (your domain, and organization details for OV/EV)
- Issuer — which CA signed and issued the certificate
- Valid from / Valid to — the certificate's validity window
- Subject Alternative Name (SAN) — every hostname the certificate covers; this is what browsers check for hostname matching, not the Common Name
- Public key — the algorithm and key size (e.g. RSA 2048-bit, or ECDSA 256-bit)
- Signature algorithm — the hashing/signing algorithm the CA used (e.g. SHA-256 with RSA)
- Serial number — a unique identifier for this specific certificate, used in revocation checks
- Fingerprint — a unique hash of the whole certificate, useful for manually verifying you're looking at the exact certificate you expect
When this is worth checking manually
Most people never need to look past the padlock — but it's worth knowing how when debugging a mismatch error, verifying a certificate after renewal, or investigating an unexpected warning. The same fields are visible via openssl s_client -connect yourdomain.com:443 from the command line, useful for checking a server directly without a browser's caching getting in the way.
Why the Fingerprint field matters more than it might seem at first
The fingerprint is a unique hash of the entire certificate, useful specifically for manually confirming you're looking at the exact certificate you expect — comparing a fingerprint against a known-good value is a reliable way to detect a substituted or unexpected certificate that a casual visual check of the other fields might miss.
Doing the same check from the command line instead of a browser
Running `openssl s_client -connect yourdomain.com:443` followed by `openssl x509 -noout -text` shows every field a browser's certificate viewer shows, from the server, without any browser caching or summarization getting in the way — useful specifically when debugging a mismatch between what you expect and what a browser is in practice reporting.
Why the Serial Number field matters for revocation
A certificate's serial number is the unique identifier a CA references when publishing a revocation list or responding to an OCSP query, meaning revocation checking fundamentally works by looking up this exact number rather than any other field on the certificate.
What the Signature Algorithm field is actually telling you
This field identifies the specific algorithm the issuing CA used to sign the certificate, commonly SHA-256 with RSA or ECDSA today — it's the CA's own signing algorithm, distinct from the certificate's own public key algorithm, and worth checking precisely if you're auditing for any lingering use of deprecated algorithms like SHA-1.
Why comparing two certificates side by side is a useful troubleshooting technique
When debugging why one certificate works and a seemingly similar one doesn't, viewing both side by side, ideally via the raw OpenSSL text output rather than a browser's summarized view, often reveals the specific differing field, an extra SAN entry, a different key usage extension, that's actually causing the discrepancy.
Why this skill pays off well beyond just satisfying curiosity
Being able to read a certificate's raw fields directly turns nearly every certificate-related error message from an opaque black box into something you can really diagnose yourself, without needing to guess or search for an explanation every time something looks unfamiliar.
What a completed, worked example looks like reading through every major field
Working through a real certificate's Subject (identifying the domain), Issuer (identifying the CA), Validity (confirming it's current), and SAN list (confirming coverage) as a single guided exercise cements the individual field knowledge covered throughout this article into one practical, repeatable skill.
See RFC 5280, the X.509 certificate profile defining every field.
Loading comments…