Free online X.509 certificate decoder. Paste a PEM certificate to view Subject, Issuer, validity period, public key algorithm, fingerprint, and more.
TL;DR: Free X.509 certificate decoder: local PEM parse of subject, issuer, validity, SAN, Key Usage, with SM2/SM3 OID names. Certificates are never uploaded.
For local tools, open DevTools → Network and search your input — it should not appear in requests.
Usage Guide
An HTTPS certificate (PEM/CRT) is a Base64-encoded X.509 structure: issuer, subject, validity window, the SAN domain list, public-key algorithm, and key usage all live inside. Certificate troubleshooting, expiry audits, and rotation acceptance all start the same way — take the cert apart and read it. This tool parses PEM entirely in your browser and answers “who signed it, which domains, until when, at what key spec” without uploading anything.
1. Decoding a certificate
DER binaries need conversion to PEM (Base64 with headers) first; CSRs and private-key blocks are out of scope.
- Paste the PEM text (-----BEGIN CERTIFICATE----- blocks; bundles split automatically).
- Read the parse: Subject/Issuer, NotBefore/NotAfter, SAN list, key algorithm and size, Key Usage / Extended Key Usage.
- Check against expectations: every domain present in SAN, validity window, complete chain.
2. The three classic browser errors
① Name mismatch: modern browsers match only the SAN — a correct CN with a missing SAN entry still fails. ② Expired or not-yet-valid: past NotAfter, or clock drift failing NotBefore (containers with wrong time are a recurring incident). ③ Incomplete chain: the server sent only the leaf without intermediates — the number-one cause of “works on desktop, fails on phones”, since some clients don’t cache intermediates. Identify the class here first, then touch nginx/CDN config; it beats blind edits.
3. Key usage and algorithms: the cert’s spec sheet
Key Usage declares what the certificate may do (signing, key encipherment, CA issuance); Extended Key Usage narrows the scenario (serverAuth, clientAuth, code signing) — a wrong EKU fails handshakes. On algorithms check two spots: key type and size (RSA 2048+/ECDSA P-256+ are mainstream; RSA 1024 and SHA-1 are end-of-life) and the signature algorithm (SHA-256 at minimum). Self-signed and internal-CA certificates are fully well-formed — validity is not this page’s verdict (see below), but spec defects are visible at a glance.
4. China SM2 dual certificates (TLCP)
The Chinese TLS profile (TLCP) pairs a signing certificate with an encryption certificate; the field and OID layout differs from international chains. This page reads each certificate’s fields and role split; full TLCP handshakes and CRL/OCSP revocation need a dedicated toolchain outside a browser decoder — a capability boundary stated as it is.
5. Trust boundary: parsing ≠ trusting
Anyone can generate a well-formed certificate — complete fields, valid syntax. Trust depends on the chain terminating at an anchor you trust and on revocation status. This page is a microscope, not a judge: it dissects the certificate; verdicts belong to openssl verify, the browser, or your trust store. Internalizing this boundary prevents the dangerous shortcut “it parsed, therefore it’s trusted”.
6. Ops practice
- Expiry hygiene: build the ledger from NotAfter with 30/7/1-day alert tiers; after renewal, decode the new cert and confirm its SAN still covers every business domain.
- Rotation acceptance: diff the Subject Key Identifier and public key — prove the key actually changed rather than the same cert being re-issued.
- Tickets: paste decoded text (minus sensitive fields) instead of screenshots — searchable and unambiguous; label each block in a chain bundle.
7. Privacy and the red line
Certificates are public material — anyone can fetch them during a handshake, so pasting one is harmless. The danger is a PEM file that also contains its private key: confirm you are pasting only CERTIFICATE blocks. A PRIVATE KEY block must never enter any tool, local or online. Certificate Transparency logs publish issuance records anyway; the private key remains the one thing worth protecting.
FAQ
PEM text (-----BEGIN CERTIFICATE-----): Subject / Issuer / validity / signature and public-key algorithms / SAN / Key Usage. Pasting a blob with several certificates auto-splits them for viewing one by one. Raw DER must be converted to PEM first, and CSR is out of scope.
Yes — common Guomi OIDs (e.g. SM2 with SM3, SM2 Public Key) are labeled, and Key Usage is parsed so you can tell a TLCP signing cert (digitalSignature) from an encryption cert (keyEncipherment / keyAgreement). This page only reads X.509 fields; it does not run a TLCP / ShangMi handshake. See the Guomi HTTPS / nginx guide on this site for deployment.
A certificate is public material — anyone can download one during a TLS handshake — and this page parses it locally. The real hazard is a private-key block hiding in the same PEM file: check that you are pasting CERTIFICATE blocks only; PRIVATE KEY material must never go into any online tool.
Each decode shows one leaf or intermediate certificate (including SAN and Key Usage); the page does not build paths, validate them, or check revocation. Whether the full chain is served and trusted still needs the server-side dump (e.g. openssl s_client) or an external chain checker.
Three classics. (1) Name mismatch: modern browsers match on SAN only, so a correct CN with a missing SAN entry still errors. (2) Expired or not yet valid: NotAfter has passed, or clock drift fails the NotBefore check — wrong time inside containers is a frequent incident. (3) Incomplete chain: the server sends only the leaf cert, the number-one reason a site works on desktop yet fails on phones and mini-programs, since some clients never cache intermediates. Decode here to see which class it is before touching nginx or the CDN.
No. Anyone can produce a certificate with complete fields and valid formatting; trust depends on whether the chain ends at a root you trust and whether the certificate has been revoked. This page is a microscope, not a judge — leave the verdict to openssl verify, your browser, or your trust store.
Related Tools
Related Articles
Online Certificate Decoder: Parse SSL/TLS Certificate Information
Decode PEM certificates locally: Subject, Issuer, SAN, validity, and chain context. Pair with OpenSSL for hostname mismatch, missing intermediates, and clock skew — nothing is uploaded.
Incomplete HTTPS Certificate Chain: Browser Distrusts a “Valid” Leaf
Leaf dates and SAN look fine, but clients still reject the cert? Usually a missing intermediate or misordered fullchain. Verify Issuer→Subject with openssl s_client and a local decoder.
Guomi HTTPS Deployment Guide: TLCP Protocol, SM2 Dual Certificates, and nginx with Tongsuo
Guomi HTTPS under assessment / MLPS pressure: TLCP (GB/T 38636) vs RFC 8998, how signing and encryption certificates differ, building nginx with Tongsuo, dual-stack coexistence, handshake troubleshooting order, and what browser SM tools can and cannot prove.