An SSL certificate decoder that never uploads your certificates
This SSL certificate decoder reads X.509 certificates, whole certificate chains, PKCS#7 (.p7b) bundles and certificate signing requests (CSRs) and shows everything inside them in plain language: subject and issuer, every Subject Alternative Name, validity dates with the days left, key type and size, signature algorithm, serial number, extensions and SHA-1 / SHA-256 fingerprints. It is the information openssl x509 -text prints, organised and explained.
It also checks what usually goes wrong. Each certificate is tested for expiry, SHA-1 signatures, RSA keys under 2,048 bits, missing SANs and over-long lifetimes; a pasted chain is checked link by link — names and signatures, verified with your browser’s Web Crypto API — and the correct order is suggested when the server sends it wrong. The decoder is written from scratch as a small ASN.1 parser in this page, so nothing is sent anywhere.
How to use the SSL Certificate Decoder
- Paste one or more PEM blocks (
-----BEGIN CERTIFICATE-----or-----BEGIN CERTIFICATE REQUEST-----) into the box, or drop a .crt, .cer, .pem, .der, .csr or .p7b file. - Read the summary: number of certificates, soonest expiry and serious problems.
- For a chain, check Chain order: each arrow shows whether the next certificate really issued the one above it and whether the signature verified.
- Open each certificate card for its findings and every field. Copy a fingerprint or the SPKI pin with the button beside it.
- Press Copy text report to paste the decoded details into a ticket or audit note.
SSL Certificate Decoder features
Complete X.509 decoding
Subject, issuer, serial, validity, key (RSA size and exponent, EC curve, Ed25519), signature algorithm and extensions: key usage, extended key usage, basic constraints, SKI/AKI, AIA, CRL distribution points, policies with DV/OV/EV names, name constraints, TLS feature and SCTs.
Certificate Transparency SCTs
Each embedded signed certificate timestamp is listed with its log ID, timestamp to the millisecond, version and signature algorithm.
Real chain verification
RSA PKCS#1, RSA-PSS, ECDSA P-256/384/521 and Ed25519 signatures are checked with Web Crypto, and out-of-order chains get a corrected order.
CSR checks
Shows the requested subject, SANs and extensions and verifies the CSR’s own signature, which proves it was made with the matching private key.
Many formats
PEM or binary DER, multiple certificates at once, PKCS#7 bundles from Windows or OpenSSL, and clear guidance for .pfx files and accidentally pasted private keys.
What the warnings mean
| Finding | Why it matters |
|---|---|
| Expired / expires in under 30 days | Clients refuse expired certificates; most outages happen because nobody renewed in time |
| SHA-1 or MD5 signature | Collisions are practical, so browsers stopped trusting these signatures (except on roots, where the signature is not used) |
| RSA key under 2,048 bits | Below the minimum for publicly trusted certificates since 2014 |
| No Subject Alternative Name | Browsers match host names only against SANs, ignoring the Common Name |
| Lifetime over the CA/Browser Forum limit | 398 days for certificates issued from September 2020, 200 days from 15 March 2026 |
| Chain out of order or incomplete | Some clients cannot build the path and show “unable to verify the first certificate” |
Worked example: the example chain
Press Load example chain to decode the chain served by letsencrypt.org. Certificate 1 is the leaf: CN=letsencrypt.org with ten DNS names, an EC P-256 key and an ecdsa-with-SHA384 signature from the intermediate YE2, valid from 4 September to 3 December 2026 — Let’s Encrypt’s 90-day lifetime. Its SHA-256 fingerprint is 1F:C4:F6:97:…:9A:53, identical to openssl x509 -fingerprint -sha256. Two SCTs show it was logged in Certificate Transparency before issue.
Certificates 2 to 4 are YE2, Root YE and ISRG Root X2 cross-signed by ISRG Root X1. Every arrow is green because each signature verifies with the next certificate’s key; the last one points to ISRG Root X1, which browsers already trust and the server rightly does not send.
Fingerprints and pins
A fingerprint is a hash of the whole certificate, useful for confirming you are looking at exactly the same file. The SPKI pin is the Base64 SHA-256 of the public key alone, the value used for key pinning and by tools such as curl --pinnedpubkey; it stays the same when a certificate is renewed with the same key. To hash any other file, use the File Hash Checker; to decode Base64 by hand, the Base64 Encoder. For HTTPS hardening beyond certificates, see the CSP Generator.
SSL Certificate Decoder FAQ
How do I decode an SSL certificate?
Open the .crt or .pem file in a text editor, copy everything from -----BEGIN CERTIFICATE----- to -----END CERTIFICATE----- and paste it into the SSL certificate decoder, or simply drop the file onto the page. Binary .der and .cer files work too.
Is it safe to paste my certificate here?
Yes. Certificates and CSRs are public by design, and this page decodes them locally anyway — nothing is uploaded. Never paste a private key into any website; if you do here, it is ignored and you are warned.
How can I check whether my certificate chain is in the right order?
Paste the full chain exactly as your server sends it. The tool checks that each certificate is issued by the next one, verifies each signature, and if the order is wrong shows the correct sequence, leaf first.
How do I decode a CSR before sending it to a CA?
Paste the CERTIFICATE REQUEST block. You will see the subject, key size, requested SANs and key usages, and whether the CSR’s signature verifies, so you can catch a wrong domain or weak key before paying for a certificate.
Why does my browser say the certificate is invalid when the dates are fine?
Common causes are a missing intermediate certificate, a host name that is not in the SAN list, a self-signed or private-CA certificate, or a SHA-1 signature. The findings for each certificate point to the specific problem.
What is the difference between the SHA-1 and SHA-256 fingerprint?
Both identify the same certificate; they are just different hash functions over the same bytes. SHA-256 is the one to compare today, but some older tools and Windows dialogs still display SHA-1 thumbprints.