SSL Certificate Decoder
Decode a PEM X.509 SSL certificate to read its subject, issuer, SANs, key size and expiry date — parsed in your browser, never uploaded.
Certificate
PEM — paste the whole block including the BEGIN and END linesPaste a PEM certificate above, or open a .pem, .crt or .cer file. Everything is decoded in your browser.
Parsed locally with an ASN.1 reader in your browser — the certificate is never uploaded. This SSL certificate decoder reads what the certificate says; it does not verify the signature or build a chain.
About the SSL Certificate Decoder
Paste a PEM block and this SSL certificate decoder reads it: subject, issuer, serial number, validity dates, key algorithm and size, subject alternative names, key usage and every extension it recognises. It is an ASN.1 DER parser and an implementation of the RFC 5280 certificate structure, running entirely in your browser.
That last part is the reason to use this rather than one of the incumbents. A certificate is public — it is served to anyone who connects — but pasting one into a website that POSTs it somewhere still tells that site which hosts you run, when they expire and who issues them. Here the file is read with the File API and parsed locally. You can confirm it by decoding a certificate with your network disconnected.
Paste a full chain and each certificate becomes a tab, so you can walk from the leaf up to the root and see where the path actually ends. Fingerprints are computed with WebCrypto over the DER, which is exactly what a browser's certificate viewer shows you.
What this does not do is verify anything. There is no chain building, no signature check and no revocation lookup, because none of those are possible from a single pasted certificate — they need the issuer's certificate and a trust store. Everything reported here is a statement about what the certificate says, and the tool never implies more than that.
- Full ASN.1 DER parser, so extensions are decoded rather than shown as hex
- Subject and issuer distinguished names broken into their attributes
- Subject alternative names, including DNS, IP, email and URI entries
- Key usage bits, extended key usage purposes and basic constraints decoded to plain English
- RSA modulus size and EC curve name read from the key itself
- SHA-256 and SHA-1 fingerprints, computed locally with WebCrypto
- Findings for expiry, SHA-1 signatures, weak keys, a missing SAN and an over-long validity period
- Whole chains, each certificate on its own tab
How to use it
- Paste the PEM block, including the BEGIN and END lines, or open a .pem, .crt or .cer file.
- Read the Findings panel first — it puts expiry, weak keys and a missing SAN at the top rather than burying them in the field list.
- Check the subject alternative names. Since Chrome 58, the common name is ignored entirely: if a hostname is not in the SAN list, the certificate does not cover it.
- Compare a fingerprint against the one your browser or monitoring shows to confirm you are looking at the same certificate.
- For a chain, use the tabs to walk from the leaf to the root.
Real-world use cases
Backend & platform engineers
Confirm a certificate's SAN list and expiry after rotating it in a load balancer or reverse proxy, before traffic depends on the change being correct.
DevOps & SRE teams
Check the validity window and issuer of a certificate during an incident, or as part of a pre-expiry audit across a fleet of internal services, without hitting an external tool for every internal-only host.
Security engineers
Inspect the full extension set of a certificate — key usage, basic constraints, SANs — during a review, and catch a SHA-1 signature or an over-long validity period before it becomes a finding in someone else's audit.
QA & release engineers
Verify a certificate deployed to a staging environment matches what was actually requested — same SANs, same key size — before promoting the configuration to production.
Support & debugging engineers
Decode a chain a customer pasted into a ticket to see immediately whether the intermediate certificate is missing, the single most common cause of "works in my browser, fails everywhere else."
Examples
What a leaf certificate reports
-----BEGIN CERTIFICATE----- MIIF… -----END CERTIFICATE-----
Subject: CN=example.com Issuer: C=US, O=Example CA, CN=Example CA R3 Key: RSA · 2048 bits SANs: DNS:example.com, DNS:www.example.com
Two names in the SAN list, so this certificate covers example.com and www.example.com and nothing else.
A wildcard's actual reach
DNS:*.example.com
Covers api.example.com Does not cover a.b.example.com, example.com
A wildcard matches exactly one label. The apex domain needs its own SAN entry, which is why most wildcard certificates list both.
Key usage decoded
2.5.29.15 (BIT STRING 03 02 05 A0)
Digital signature, Key encipherment
The bits are read in specification order. This pair is what an ordinary TLS server certificate carries.
An over-long validity period
notBefore 2026-01-01, notAfter 2028-01-01
Warning: validity period is 730 days.
Public CAs cannot issue leaf certificates for more than 398 days. A longer one is either privately issued or will be rejected by browsers.
Common errors
| Message | Cause | Fix |
|---|---|---|
| NET::ERR_CERT_COMMON_NAME_INVALID | The hostname is not in the subject alternative name list. Chrome has ignored the common name since version 58. | Check the SAN panel above. If the hostname is not listed there, reissue the certificate with it included — putting it in the CN does nothing. |
| NET::ERR_CERT_DATE_INVALID | The current time is outside the notBefore–notAfter window. Occasionally it is the client's clock that is wrong. | The validity panel shows both dates in UTC and how many days remain. A negative figure means it expired. |
| unable to get local issuer certificate | The server is not sending the intermediate certificate, so the chain cannot reach a trusted root. | Paste the full chain your server sends. If only one certificate appears, the intermediates are missing from the server configuration. |
| SEC_ERROR_UNKNOWN_ISSUER, but it works in some browsers | Usually a missing intermediate that one client happened to have cached from another site. | Same fix: serve the full chain. It working somewhere is not evidence the configuration is correct. |
| This is valid DER, but not a certificate. | The block is a private key, a certificate request or a public key rather than a certificate. | Check the BEGIN line. This tool reads CERTIFICATE blocks; a PRIVATE KEY block has a different structure — and should not be pasted into any website. |
| A value claims N bytes but only M remain. | The PEM was truncated, most often by a copy that lost the last line or the closing END marker. | Copy the whole block again including both marker lines, or open the file directly with the button above. |
Frequently asked questions
›Is my certificate uploaded?
No. The PEM is Base64-decoded and the DER parsed in your browser, and files are read with the File API. Nothing is transmitted, so nothing is logged. A certificate is public information, but which certificates you look up is not — and the incumbent tools in this category all POST it to a server.
›Does this verify the certificate?
No, and the distinction matters. Verifying means checking the signature against the issuer's public key, building a path to a trusted root, and checking revocation — none of which is possible from one pasted certificate, because you would need the issuer's certificate and a trust store. Everything here reports what the certificate asserts. A certificate can decode perfectly and still be untrusted, expired or revoked.
›Why does my certificate fail even though the common name is right?
Because the common name is no longer used for hostname matching. Chrome dropped it in version 58 and the other browsers followed; RFC 2818 deprecated it long before that. Only the subject alternative name list counts. A leaf certificate with no SAN at all matches no hostname, which is why that gets flagged as an error above.
›What does the 398-day warning mean?
The CA/Browser Forum caps publicly trusted leaf certificates at 398 days, enforced since September 2020. A leaf valid for longer than that was either issued by a private CA — which is fine inside your own network — or will be rejected by browsers regardless of who signed it. The check is skipped for CA certificates, which are legitimately long-lived.
›How far does a wildcard certificate actually reach?
One label, and only in the leftmost position. *.example.com covers api.example.com and www.example.com, but not a.b.example.com and not example.com itself. That last one surprises people constantly, which is why most wildcard certificates carry a second SAN entry for the apex domain.
›Which fingerprint should I compare?
SHA-256. Both are shown because pinning configurations and older monitoring still use SHA-1, but SHA-1 has practical collision attacks and should not be relied on for identity. Both are computed over the DER encoding, which is what browsers, openssl and certificate transparency logs all display.
›Can I paste a whole chain?
Yes. Every PEM block in what you paste is decoded, and each becomes a tab. Walking from the leaf upwards is the quickest way to see whether your server is actually sending the intermediates — the single most common cause of a certificate that works in your browser and fails in curl or on a phone.
›Does this work on internal or self-signed certificates?
Yes — decoding reads the certificate's own structure and does not depend on it being publicly trusted or issued by a well-known CA. Self-signed and internal-CA certificates decode exactly like a public one; only chain-of-trust verification (which this tool deliberately does not attempt) would differ.
Last updated