SSL Certificate Decoder — Free X.509 Certificate Inspector

Paste a PEM X.509 certificate and inspect every field — issuer, subject, validity, Subject Alternative Names, public key, SHA-256 / SHA-1 fingerprints, key usage. ASN.1 DER parsing entirely in your browser.

PEM Certificate Input

Decoded Result

Click Decode to parse a pasted certificate. Use Load Sample to try with a self-signed PEM.

What is an SSL Certificate Decoder?

An SSL certificate decoder parses the ASN.1 DER structure inside a PEM-encoded X.509 certificate and surfaces every field — issuer, subject, validity dates, Subject Alternative Names, public key algorithm and size, signature algorithm, key usage, extended key usage, and SHA-256/SHA-1 fingerprints. It tells you everything a browser sees when validating your TLS handshake.

Hand-decoding X.509 with openssl x509 -in cert.pem -noout -text is the operations standard, but a copy-paste browser tool gives the same answer in 5 seconds — useful when you are debugging a CDN-fronted endpoint, comparing a cert to a pin, or auditing a vendor cert before adding it to a trust store.

How to decode an SSL certificate — 4 steps

Get the PEM. Export from your server (cat /etc/letsencrypt/live/example.com/cert.pem) or save the leaf cert from a browser's Certificate Viewer.
Paste it. Drop the PEM block — including BEGIN/END markers — into the input box.
Click Decode. The browser walks the DER, computes SHA-256/SHA-1 fingerprints with Web Crypto, and renders a styled card.
Verify. Confirm Not After is in the future, the SAN list matches your hostnames, the issuer matches your CA, and the fingerprint matches the one your monitoring system records.

Sample input

-----BEGIN CERTIFICATE-----
MIIDazCCAlOgAwIBAgIUFq9QpjGQ8xJpFqLtTwVNAvSuUkAwDQYJKoZIhvcNAQEL
BQAwRTELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWExITAfBgNVBAoM
GEludGVybmV0IFdpZGdpdHMgUHR5IEx0ZDAeFw0yNDAxMDExMjAwMDBaFw0yNTAx
...
-----END CERTIFICATE-----

# Decoded fields
Version:    v3
Serial:     16:AF:50:A6:31:90:F3:12:69:16...
Subject:    CN=example.com, O=Acme Inc, C=US
Issuer:     CN=Let's Encrypt R3, O=Let's Encrypt, C=US
Validity:   2024-01-01 → 2025-01-01 (expired 120 days ago)
SANs:       DNS:example.com, DNS:www.example.com
Public key: RSA 2048 bits
Signature:  sha256WithRSAEncryption
SHA-256:    7B:88:21:...:9E (DER fingerprint)
EKU:        TLS Web Server Authentication, TLS Web Client Authentication

Every X.509 Field

Issuer, subject, validity, SANs, public key, signature, key usage, EKU, serial, version — surfaced from the ASN.1 DER bytes.

Real SHA-256 Fingerprint

Computed with Web Crypto over the full DER — the same value openssl x509 -fingerprint -sha256 prints, ready for pinning rules.

Expiry Awareness

A live-coloured badge flips green → orange → red as your cert approaches and passes its Not After date.

Common use cases

check_circleConfirming a Let’s Encrypt or commercial CA cert before deploying to production
check_circleChecking expiry on a forgotten staging cert before it breaks CI
check_circleVerifying SANs cover every hostname behind a multi-domain load balancer
check_circleComputing the SHA-256 fingerprint for HPKP, certificate pinning, or monitoring
check_circleAuditing an OV/EV certificate to confirm Subject DN matches what was ordered
check_circleDiagnosing self-signed vs CA-issued certs in dev environments
check_circleReviewing client certificates issued by an internal PKI / Vault / step-ca
check_circleVerifying the signature algorithm is SHA-256+ (no SHA-1, no MD5)

What fields matter most?

For a TLS server cert, four fields decide whether browsers will trust it: Subject Alternative Names must include every hostname users will type; Not After must be in the future and ideally more than 30 days away; Issuer must chain to a root in the OS/browser store (Let's Encrypt R3, ISRG Root X1, DigiCert Global Root G2, etc.); and Signature Algorithm must be SHA-256 or stronger — SHA-1 has been distrusted since 2017 and certificates signed with MD5 are rejected outright. Everything else (organisation, locality, EKU) is informational for DV certs.

Privacy & security

X.509 certificates are public — every browser that connects to your service downloads them. Decoders only parse public information. We never see private keys.

Need other SSL/TLS helpers?

Pair the cert decoder with the rest of OpenFormatter's browser-side SSL tooling — decode CSRs, build openssl req commands, generate self-signed certs, and emit Mozilla-grade TLS configs.

CSR Decoder OpenSSL Command Generator SSL Config Generator

Frequently Asked Questions

Is it safe to paste a certificate?

Yes — X.509 certificates are public by design. Every browser that connects to your site downloads them. The matching private key (PEM block labelled BEGIN PRIVATE KEY / BEGIN RSA PRIVATE KEY) is the only thing that must stay secret. Even so, this decoder runs entirely in your browser; nothing about the cert leaves the tab.

How is the fingerprint calculated?

The SHA-256 fingerprint is the SHA-256 hash of the entire DER-encoded certificate (the bytes you would get by base64-decoding the PEM body). The SHA-1 fingerprint is the same thing with SHA-1. Both are computed using the browser Web Crypto API (crypto.subtle.digest), the same primitive used by TLS internally.

What does Subject Alternative Names mean?

Subject Alternative Names is the X.509 v3 extension (OID 2.5.29.17) that lists every hostname, IP, email, or URI the certificate is valid for. Modern browsers ignore the legacy CN field and validate strictly against SAN — a cert without SAN entries fails on Chrome, Firefox, and Safari regardless of CN.

What are Key Usage extensions?

Key Usage (OID 2.5.29.15) is a bitmask declaring what the public key is allowed to do — Digital Signature, Key Encipherment, Certificate Sign, CRL Sign, and so on. A TLS server cert needs Digital Signature + Key Encipherment (RSA) or Digital Signature (ECDSA). Extended Key Usage (EKU) refines this with purpose OIDs like TLS Server Auth (1.3.6.1.5.5.7.3.1) and Client Auth.

How do I check expiry?

Decode the cert and look at the Validity section — Not Before is the issue date, Not After is the expiry. The decoder colour-codes the badge: green if more than 30 days remain, orange if expiring within 30 days, red if already expired. Set up renewal at least 21 days before expiry to leave time for issuance, deployment, and DNS propagation.

Why does my cert show issuer = self?

When the Issuer DN matches the Subject DN exactly, the certificate is self-signed — it certifies itself rather than being signed by a CA. Self-signed certs are perfect for local development and internal services but trigger browser warnings on the public internet. Use a real CA (Let’s Encrypt is free) for anything users will see.

What is the difference between issuer and subject?

Subject is who the certificate is for (the CN/SANs the cert vouches for). Issuer is the Certificate Authority that signed it — DigiCert, Let’s Encrypt R3, Sectigo, GlobalSign, etc. To validate the chain, the verifier looks up the issuer cert (typically an intermediate) and walks up to a trusted root in the OS or browser store.

Can I decode certificate chains?

This decoder reads one cert at a time. To inspect a full chain (leaf → intermediate → root), paste each PEM block separately. Most chain files concatenate three PEM blocks; copy each between BEGIN/END markers and decode in turn to confirm the issuer of the leaf matches the subject of the intermediate, and so on.