SSL Certificate Decoder
Paste a PEM, Base64, DER or PKCS #7 certificate or a whole chain. See SANs, validity, key, extensions and SCTs, and check chain order and signatures locally.
- Runs in your browser
- Your data never leaves your browser
- Free · No Sign-Up
Scan with WeChat to share this tool
Examples, details and FAQ Worked examples, how it compares with other tools, and answers to common questions.
Example: the chain www.example.com sends
Click Example to load the four certificates www.example.com returned to openssl s_client -showcerts on 2026-10-01. The tool reports:
| # | Subject CN | Role | Signed by the next certificate |
|---|---|---|---|
| 1 | example.com | Leaf | signature verified |
| 2 | Cloudflare TLS Issuing ECC CA 3 | Intermediate CA | signature verified |
| 3 | SSL.com TLS Transit ECC CA R2 | Intermediate CA | signature verified |
| 4 | SSL.com TLS ECC Root CA 2022 | Intermediate CA | issuer not in the input |
Certificate 4 is the SSL.com root in a cross-signed form: its issuer is CN=AAA Certificate Services,O=Comodo CA Limited,L=Salford,ST=Greater Manchester,C=GB. The server does not send that root, which is normal: clients that trust it already have it.
For the leaf, the tool shows:
- Not before
2026-09-26 22:49:11 UTC, not after2026-12-25 22:56:35 UTC. - Validity period 91 days. The span is 90 days and 7 minutes, and the Baseline Requirements §6.3.2 count any part of a day as a day.
- SHA-256 fingerprint
85:CA:6A:B0:68:E9:BC:CE:88:B6:C4:AA:3C:47:F7:D1:72:28:13:4A:45:7F:87:0D:38:00:E6:22:3A:0D:F0:7A. It is the same value thatopenssl x509 -noout -fingerprint -sha256prints. - Two Certificate Transparency SCTs, with log IDs and timestamps.
- Hostname check:
www.example.commatches the wildcard SAN*.example.com;a.b.example.comdoes not, because a wildcard covers exactly one label (RFC 9525 §6.3).
Example: a chain in the wrong order
Servers send the leaf first and each issuer after the certificate it signed (RFC 8446 §4.4.2). Nginx asks for the same order in the file you give to ssl_certificate: “The server certificate must appear before the chained certificates” (nginx docs).
Take the four certificates letsencrypt.org sent on the same day and paste them in reverse order. The tool says: Order is wrong or the input mixes chains. Path from the leaf: #4 → #3 → #2 → #1. Each link still shows “signature verified”, so the certificates belong together; only the order is wrong. Copy in suggested order gives you the file in leaf-first order.
If you paste only a leaf, the chain card says the issuer is not in the input and shows the Authority Information Access URL where the CA publishes it. Browsers often download a missing intermediate that way; Java leaves AIA fetching off by default, and Go’s TLS stack does not do it (golang/go#31773), so fix the server instead.
What the tool checks
| Check | Rule |
|---|---|
| Signature algorithm inside and outside tbsCertificate match | RFC 5280 §4.1.1.2 |
| Serial number positive and at most 20 octets | RFC 5280 §4.1.2.2 |
UTCTime / GeneralizedTime with seconds and Z; UTCTime until 2049 | RFC 5280 §4.1.2.5 |
| Unknown critical extension, duplicate extension | RFC 5280 §4.2 |
| No SAN (browsers ignore the CN; Chrome removed CN matching in version 58) | RFC 9525 |
| SHA-1 or MD5 signature, RSA key under 2048 bits | CA/B Forum Baseline Requirements |
| Leaf validity longer than the Baseline Requirements allow for its issue date (398, 200, 100, then 47 days; ballot SC-081) | BR §6.3.2 |
| Issuer is a CA, has keyCertSign, path length not exceeded | RFC 5280 §4.2.1.3, §4.2.1.9 |
Times are shown in UTC next to the raw encoded value, so a +0800 offset or a missing second stays visible. Key sizes come from the key itself: a P-521 key is 521 bits, not 528.
The fingerprint card has SHA-256, SHA-1 and MD5 of the DER bytes, plus the SHA-256 of the SubjectPublicKeyInfo in Base64, the pin-sha256 format from RFC 7469 that Android network security config and OkHttp pins use.
Input formats
- PEM blocks labelled
CERTIFICATE, the legacyX509 CERTIFICATE, and OpenSSL’sTRUSTED CERTIFICATE(RFC 7468); text around the blocks, CRLF line endings and extra spaces are ignored. - Base64 without the BEGIN / END lines, as some control panels show it.
- Binary DER files and PKCS #7 bundles (
.p7b), in PEM or DER. A loaded binary file is converted to PEM in the box. - Certificate signing requests, public keys and CRLs are recognised and named, not decoded. For CSRs use the CSR Decoder.
Errors point at the place. A stray character gives “Line 4, column 5: ”*” is not a Base64 character”. If one 64-character line of the example.com leaf is lost while copying, the message is “Certificate at byte 0 needs 1002 bytes but only 954 remain”.
How it compares
Tested on 2026-10-01 with the same files:
| Tool | Where it decodes | Chain of 4 certificates |
|---|---|---|
| SSL Shopper Certificate Decoder | Sends the text to its server (ajax_decode.php) | “We were unable to decode this certificate” |
| CertLogik | Posts the form to its server | Shows the first certificate only |
| Report URI PEM Decoder | Posts the text to its server | Shows the first certificate only; rejects Base64 without the PEM header |
| This tool | In the page | All four, with order and signature checks |
SSL Shopper also shows dates without a time zone: a certificate that starts at 2026-01-01 00:00 UTC appeared as “Valid From: December 31, 2025”. For certificates of internal hosts, decoding in the page keeps their host names away from third parties.
Limits
- No trust store, no revocation (OCSP / CRL) check, no live TLS connection. Fetch a chain with
openssl s_client -connect host:443 -showcerts, or look up records with the DNS Lookup tool and inspect response headers with the HTTP Header Analyzer. - Signatures are verified with Web Crypto: RSA (PKCS #1 v1.5 and PSS), ECDSA on P-256, P-384 and P-521, and Ed25519 where the browser supports it. ML-DSA, Ed448, DSA, SM2, MD5 and SHA-224 signatures are decoded but reported as not checked.
- Name constraints are shown but not applied to the leaf’s names.
- Files up to 1 MB and up to 200 certificates per input.
FAQ
Is the certificate uploaded anywhere?
No. The decoder runs in the page: a DER parser written in JavaScript plus the browser's Web Crypto API for fingerprints and signature checks. The certificate is never sent to a server. The page itself loads Google Analytics and AdSense like other ZeroTool pages; they do not receive the text you paste.
Can I paste a full chain or a fullchain.pem file?
Yes. Every certificate in the input is decoded. The tool checks that each certificate is followed by the one that issued it, verifies each signature with the next certificate's public key, and offers to copy the chain in the correct order when it is wrong.
What happens if my file also contains the private key?
Blocks such as PRIVATE KEY, RSA PRIVATE KEY or EC PRIVATE KEY are skipped without being decoded, and input that contains one is not saved in the browser. PKCS #12 (.pfx / .p12) files are not opened at all. Extract the certificates first with openssl pkcs12 -nokeys.
Does it tell me whether a browser trusts the certificate?
No. It has no trust store and does not check revocation. It tells you whether the chain you pasted is complete, ordered and correctly signed. Use openssl verify or your platform's trust store for the trust decision.
Why does the validity period show one day more than I expected?
The validity period counts both notBefore and notAfter, as RFC 5280 defines it, and any part of a day counts as a day, as the CA/Browser Forum Baseline Requirements count it. A certificate from 00:00:00 to 23:59:59 on the 90th day is 90 days; one that ends a few minutes later is 91.