How to read an SSL certificate (without the jargon)
Certificates run the trust layer of the web, and yet most people only meet them as an error message. The format is genuinely readable once you know which five fields carry the story — and every error message maps to one of them. Drop any certificate into the certificate decoder as you read; everything below is decoded for you, locally.
The five fields that matter
Subject — who the certificate is for. For websites the meaningful part is not the Common Name (legacy) but the Subject Alternative Names: the actual list of hostnames covered. If your hostname isn't in that list, exactly or via a one-label wildcard, nothing else about the certificate matters. Issuer — who vouches for it: a real certificate authority, a corporate CA, or (if issuer equals subject) nobody but itself. Validity — the not-before/not-after window; public TLS certificates now run 90–398 days by rule, which is why automation replaced calendar reminders. Public key — the algorithm and strength (RSA 2048+ or EC P-256 are today's norms). And the fingerprints — hashes of the whole certificate, the reliable way to confirm "the server is serving the cert I think it is".
Chains: why your certificate is really three certificates
No public CA signs your certificate with its precious root key directly. Instead: your certificate is signed by an intermediate, the intermediate by the root, and the root lives pre-installed in every OS and browser. Clients verify the whole chain — leaf, intermediate, root — and here's the operational catch: your server must present the intermediate, because clients only carry roots. Forgetting it produces the web's most confusing failure mode: browsers (which cache intermediates from other sites) shrug and connect, while curl, Java apps, webhooks and mobile SDKs fail with "unable to verify the first certificate". The decoder's chain view orders whatever you paste leaf→root and flags the gap explicitly — see missing intermediate for the fix per server.
Decoding the classic errors
"Your connection is not private" / NET::ERR_CERT_DATE_INVALID — the validity window: either expired (renew and reload the service; with ACME, find out why auto-renewal didn't fire) or not yet valid — which, on a client machine, usually means the CLOCK is wrong, not the certificate. NET::ERR_CERT_COMMON_NAME_INVALID — a name mismatch: the hostname isn't in the SANs; the decoder's "does this cert cover…" checker answers it definitively, wildcard rules included. NET::ERR_CERT_AUTHORITY_INVALID — the chain doesn't reach a trusted root: a self-signed certificate, an internal CA the device doesn't trust, or that missing intermediate again. Warnings about weak crypto — SHA-1 signatures or RSA keys under 2048 bits: reissue with modern parameters; there's no configuration workaround.
Keys, CSRs and .pfx files: the sensitive half
Everything above is public. The private key side is not, and mixing the two up causes real incidents. A .key file or a BEGIN PRIVATE KEY block is a secret — never mail it, never paste it into web forms, never commit it. A CSR is the public request you send a CA (check its SANs BEFORE submitting; names you didn't request won't appear in the certificate). A .pfx/.p12 bundles certificate AND private key under a password — treat the file as a credential. The one legitimate everyday task with these: confirming a key matches a certificate before deploying the pair — the decoder does that comparison locally, which is rather the point.
A two-minute health check for any site you run
Pull the live certificate (openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509, or export it from the browser's padlock), drop it into the decoder, and read three lines: the expiry countdown (green means >30 days), the hostname check against your real hostnames (including the bare domain!), and the problem cards (each links to its fix). Do the same once more after any renewal — the classic renewal failure is a new certificate issued but the old one still being served.