Online Certificate Decoder: Parse SSL/TLS Certificate Information

What Are SSL/TLS Certificates

SSL/TLS certificates establish encrypted connections. They carry the server's public key, identity fields, and a CA signature. Decode any PEM certificate with our free Certificate Decoder — parsing runs entirely in your browser.

Certificate Structure

Certificate
├── Version
├── Serial Number
├── Signature Algorithm
├── Issuer
├── Validity
│   ├── Not Before
│   └── Not After
├── Subject
│   ├── Common Name (CN)
│   ├── Organization (O)
│   └── Country (C)
├── Public Key Info
├── Extensions
│   ├── Subject Alternative Names (SAN)
│   ├── Key Usage
│   └── Basic Constraints
└── Signature

Why You Need Certificate Decoding

1. Security audit: Confirm what you actually deployed
2. Troubleshooting: Turn browser red screens into field-level facts
3. Expiry monitoring: Catch Not After and intermediate expiry
4. Compliance: Check algorithms and key sizes against policy
5. Dev hygiene: Spot self-signed or staging certs that leaked to prod

Key Certificate Fields

How to Use the On-Site Tool

Using ToolVault's Certificate Decoder:

1. Paste PEM text (the full block starting with -----BEGIN CERTIFICATE-----)
2. Read Issuer, Subject, validity, SAN, public-key algorithm, and fingerprint
3. For a fullchain (multiple BEGIN CERTIFICATE blocks), paste one block at a time so you can read leaf vs intermediate

To inspect a live site, export the PEM with OpenSSL or your browser first — this tool does not fetch certificates by domain. Certificates are public, but proxying outbound connections would create an SSRF surface and conflict with the “nothing leaves the browser” promise.

Viewing Certificates with OpenSSL

# View detailed certificate info
openssl x509 -in certificate.pem -text -noout

# Validity window
openssl x509 -in certificate.pem -dates -noout

# Subject / issuer
openssl x509 -in certificate.pem -subject -noout
openssl x509 -in certificate.pem -issuer -noout

# Pull the chain (always pass -servername or SNI may serve the wrong cert)
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

Save each BEGIN CERTIFICATE block from s_client and check that each Issuer matches the next Subject.

Reading the chain, not just the leaf

A leaf alone is half the story. Browsers need leaf → intermediate → trusted root. Decoding all tiers exposes what “unable to verify” usually means:

• Missing intermediate (serve fullchain, not leaf-only)
• Expired intermediate (leaf dates still look fine)
• Wrong bundle order (must be leaf → intermediate → root)

A leaf-only decoder can say “valid” while browsers fail. For a step-by-step triage, see Incomplete certificate chain troubleshooting.

SAN, wildcards, and what covers what

Modern browsers check Subject Alternative Name only — Common Name is ignored for host matching. www.example.com does not cover example.com and vice versa. A wildcard *.example.com covers exactly one label (api.example.com yes, v1.api.example.com no, apex example.com no). Most “name mismatch” incidents decode to a SAN list that never contained the hostname.

The three timing traps in certificate lifecycles

1. notBefore skew: CA clocks vs your hosts — “works on one box, fails on another” is often skew, not revocation
2. Chain-expiry cascade: an expired intermediate invalidates leaves that still look “in date”
3. CRL/OCSP lag: a freshly revoked cert can still validate for hours; “it checks out” is a statement about freshness

The five decode findings worth memorizing

How this ties to other crypto tools

• RSA key size / padding context: RSA encrypt & decrypt guide
• SM2 dual-cert / TLCP deployments: Guomi TLS nginx guide
• Keep transport certs separate from application tokens (JWT) — decoding certs does not validate JWTs; for claim timing see JWT exp/nbf clock skew

Implementer's note

The on-site decoder is a hand-rolled ASN.1/DER subset parser in the browser. It does not run full PKIX path building via WebCrypto (WebCrypto does not expose that). So it answers “what does this PEM say?”, not “will the OS trust it?”. Domain fetch is intentionally absent: server-side fetch is an outbound SSRF footgun and breaks the local-only product promise. Use openssl verify or SSL Labs when you need trust decisions; use this page when you need field clarity.

Field checklist when something “looks valid” but browsers disagree

Decode the leaf PEM first, then walk this list before blaming the CDN:

1. SAN vs CN — modern clients match Subject Alternative Name, not only Common Name. A CN that matches with an empty or wrong SAN still fails.
2. Not Before / Not After — include clock skew; “expired tomorrow” on a host with a wrong timezone is still expired for clients in UTC.
3. Issuer continuity — leaf Issuer must equal intermediate Subject; missing intermediates produce “incomplete chain” even when the leaf alone looks fine in a decoder.
4. Key usage / EKU — server auth vs client auth; a correctly signed cert can still be rejected for the wrong purpose.
5. Signature algorithm — legacy hashes may decode fine and still trip policy on hardened clients.

The Certificate Decoder answers (1)–(2) and the identity fields quickly. Chain assembly and trust anchors still need openssl verify or the platform store — that split is intentional.

FAQ

What's the Difference Between PEM and DER?

PEM is Base64 text (-----BEGIN CERTIFICATE-----). DER is binary. Convert with openssl x509 -inform DER -in cert.der -out cert.pem before pasting.

What If a Certificate Has Expired?

1. Verify client and server clocks
2. Check whether an intermediate expired first
3. Confirm ACME/certbot actually reloaded the process
4. Self-signed certs are for development only

How to Check a Remote Server's Certificate?

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -dates -subject -issuer

curl -vI https://example.com 2>&1 | grep -A 6 "Server certificate"

Related reading

• Incomplete certificate chain troubleshooting
• Base64 vs Base64URL: JWT segments and PEM
• Guomi HTTPS: TLCP and SM2 dual certificates
• RSA encrypt & decrypt guide
• ERR_OSSL_EVP_UNSUPPORTED

Written and maintained by ToolVault. The homepage collects more browser-local tools.