SSL / TLS Certificate Decoder
Paste a PEM certificate and read its subject, issuer, validity window, SANs and key details — including whether the chain is complete.
Paste a PEM certificate to decode
Supports X.509 certificates in PEM format (Base64-encoded DER)
Certificate problems, and what actually causes them
Works in Chrome, fails in curl / Java / Android / Python
Cause:An incomplete chain. The server sends the leaf certificate but omits the intermediate that links it to a trusted root. Desktop browsers often paper over this by caching intermediates from earlier visits or fetching them via the AIA extension; almost nothing else does.
Fix:Serve the full chain: leaf first, then each intermediate in order. Omit the root — clients already have it. This is the single most common TLS misconfiguration.
NET::ERR_CERT_COMMON_NAME_INVALID
Cause:The hostname is not in the Subject Alternative Name list. Modern clients ignore the Common Name field entirely — it has been deprecated for hostname matching since RFC 2818 and browsers stopped honouring it years ago.
Fix:Every hostname the certificate serves must appear as a SAN entry. A wildcard SAN (*.example.com) covers one level only: it matches api.example.com but not a.b.example.com, and not the bare example.com.
Certificate expired despite auto-renewal being configured
Cause:Renewal succeeded but the service was never reloaded, so it is still holding the old certificate in memory. Or the ACME challenge started failing weeks ago and nobody was watching.
Fix:Add a reload hook to the renewal process, and monitor the certificate as served over the network rather than the file on disk. They are not the same thing.
A certificate valid for over 398 days is rejected
Cause:Browsers cap publicly-trusted TLS certificate lifetimes. The limit has ratcheted down over the years and continues to; long-lived public certificates are simply not issuable any more.
Fix:Automate renewal. Long validity is no longer an option for public certificates — and short lifetimes are a security improvement, since revocation has never worked reliably.
Self-signed certificate rejected in production
Cause:No trusted root vouches for it. Working as designed — a self-signed certificate provides encryption but no identity guarantee, so it cannot distinguish your server from an interceptor.
Fix:Use a publicly trusted CA for anything public. For internal services, run a private CA and distribute its root to your fleet; do not disable verification, which removes the protection entirely rather than just the warning.
Handshake fails with no clear certificate error
Cause:Protocol or cipher mismatch rather than a certificate problem. TLS 1.0 and 1.1 are disabled in current clients, and an old server offering only those has nothing to negotiate.
Fix:Support TLS 1.2 and 1.3. Disable TLS 1.0/1.1, RC4, 3DES and anything with CBC-mode SHA-1.
What the fields mean
- Subject —Who the certificate identifies. For DV certificates this is just the domain; OV and EV add verified organisation details, which browsers no longer display prominently.
- Issuer —The CA that signed it. On a leaf certificate, this must match the Subject of the next certificate in the chain — that is how you verify the chain is assembled correctly.
- Subject Alternative Name —The authoritative list of hostnames. This is what clients match against; Common Name is ignored.
- Validity period —notBefore and notAfter. A certificate is invalid before notBefore too — a common cause of failures on a machine with a badly wrong clock.
- Public key algorithm —RSA 2048 remains the safe default. ECDSA P-256 offers equivalent security with much smaller certificates and faster handshakes. RSA below 2048 bits is rejected outright.
- Signature algorithm —Should be SHA-256 or better. SHA-1 signatures have been rejected by browsers since 2017.
- Serial number —Unique per CA. You need it to request revocation, and to find the certificate in Certificate Transparency logs.
- Key usage and Extended key usage —Constrains what the certificate may be used for. A server certificate needs serverAuth; using one for client authentication or code signing requires the corresponding EKU.
The same checks from a terminal
openssl x509 -in cert.pem -noout -text
# Just the essentials
openssl x509 -in cert.pem -noout -subject -issuer -dates
# Just the SAN list
openssl x509 -in cert.pem -noout -ext subjectAltName# The definitive chain test — shows every certificate sent
openssl s_client -connect example.com:443 \
-servername example.com -showcerts
# "Verify return code: 0 (ok)" means the chain is complete.
# "unable to get local issuer certificate" means it is not.
# -servername is required: without SNI a multi-tenant host
# returns the wrong certificate and you debug a phantom.# These two moduli must be identical
openssl x509 -in cert.pem -noout -modulus | openssl md5
openssl rsa -in key.pem -noout -modulus | openssl md5
# A mismatch is why nginx refuses to start with
# "key values mismatch"About
The SSL Certificate Decoder parses and displays all fields of an X.509 certificate provided in PEM format — the base64-encoded format used by NGINX, Apache, Let's Encrypt, and most certificate authorities. Paste your PEM certificate to see: the subject (CN, O, OU, C, L, ST), the issuer (CA details), validity window and days remaining with colour-coded expiry warnings, subject alternative names (SANs), SHA-256 and SHA-1 fingerprints, the public key type (RSA or EC) and size or curve name, the signature algorithm, the serial number, and whether the certificate is a CA certificate. Decoding uses the WebCrypto API built into your browser — your certificate is never transmitted anywhere.
How to use
- 1 Paste a PEM certificate into the left panel — it should start with -----BEGIN CERTIFICATE----- and end with -----END CERTIFICATE-----.
- 2 Click "Load example" to see a demonstration with a real root CA certificate.
- 3 The tool decodes automatically after a short delay.
- 4 Check the validity banner: green = valid, amber = expires within 30 days, red = expired.
- 5 Use the copy button next to fingerprints to grab the SHA-256 value for certificate pinning.
- 6 Review the Subject Alternative Names list to confirm all intended hostnames are covered.
- How do I get the PEM certificate for my website?
- Extract it with OpenSSL: `echo | openssl s_client -connect yourdomain.com:443 2>/dev/null | sed -n "/BEGIN/,/END/p"`. Or click the padlock icon in your browser address bar, view the certificate, and export or copy the PEM data.
- What is the difference between a DER and PEM certificate?
- DER is the raw binary format of an X.509 certificate. PEM is the same data base64-encoded with -----BEGIN/END CERTIFICATE----- header lines. This tool only accepts PEM. Convert DER to PEM with: `openssl x509 -inform DER -in cert.der -out cert.pem`.
- What are Subject Alternative Names (SANs)?
- SANs are additional hostnames (and sometimes IP addresses) the certificate is valid for. Modern browsers require the hostname to be listed in SANs — the CN alone is no longer trusted. A wildcard like *.example.com covers immediate subdomains but not sub-subdomains.
- Is my certificate sent to any server?
- No. The entire decoding process uses the WebCrypto API and JavaScript — your certificate data never leaves your browser. This is safe for internal certificates, self-signed certs, or any certificate you would not want sent to a third party.
- Why does the decoder show a "Decode error"?
- Common causes: (1) Incomplete PEM — the base64 payload is truncated; (2) Multiple certificates chained together — paste only the first BEGIN/END block; (3) The PEM is a CSR or private key rather than a certificate — those are not supported.
In-depth guides
More in Network & Security
See all network & security.