X.509 Certificate Decoder & CSR Checker
Decode an X.509 certificate, a full chain bundle, or a PKCS#10 CSR, then read a lint pass that names what is actually wrong: chain out of order, CN missing from the SAN list, expiring, weak key.
About X.509 Certificate Decoder & CSR Checker
This certificate decoder reads an X.509 certificate, a full chain bundle, or a PKCS#10 CSR and renders every field: subject and issuer, subject alternative names, validity, key size, signature algorithm, serial, and the extensions. Paste PEM, a bare base64 body with no header lines, or drop a binary .der or .cer file. Rendering fields is the ordinary part. Under them runs a lint pass that says what is actually wrong: a chain in the wrong order, an intermediate that is not in the bundle at all, a Common Name that no SAN entry covers, an expired or soon-to-expire certificate, an RSA key under 2048 bits, a SHA-1 signature, CA:TRUE on something that is plainly a server certificate. Each finding names the consequence and the next step. The panel reports how many checks ran, so a clean result reads as an answer rather than an empty box. The other half of the diagnosis is the hostname test. Type the host you are actually serving and you get a yes or no against the SAN list, the entry that matched, and the RFC 6125 wildcard rules applied the way browsers apply them. Parsing happens in the page, with an ASN.1 reader written for it. Most decoders work that way now, so take it as the floor: nothing you paste is uploaded or stored, and the network tab stays quiet while you type. A certificate and a CSR are public artifacts. A server hands its certificate in the clear to every client that connects, and a CSR carries a public key plus the names you are asking a CA to sign. A private key is not public. This page detects a pasted private key and refuses to decode it. The limits, stated here rather than left for you to run into. Signatures are not verified, so chain links are matched on encoded issuer and subject names plus key identifiers: a structural answer, not a cryptographic one. There is no revocation check, no OCSP lookup and no CRL fetch. The decoder makes no network requests, so a certificate cannot be pulled from a live server, and PKCS#12 (.p12 and .pfx), PKCS#7 (.p7b) and CRL files are not read.
How to use the X.509 certificate decoder
- Paste the certificate, the whole chain bundle, or the CSR. Bare base64 with no -----BEGIN----- line works, and so does dropping a .pem, .crt, .cer, .der, or .csr file onto the box. Binary DER is converted for you, so der to pem happens on the way in rather than as a separate step.
- Read the decoded fields in the Decoded tab. Each certificate in a bundle is labelled leaf, intermediate, root, or self-signed, in the order you pasted them.
- Check the validity dates and the countdown, then copy the certificate fingerprint (SHA-256 or SHA-1) in whichever format your console wants: colon hex, plain hex, or base64. The RFC 7469 SPKI pin is there too, and it is a different number.
- Open the Checks tab. It names the problems: certificate chain order wrong, an intermediate that is not in the bundle, a Common Name missing from the SAN list, an expiring certificate, a weak key. Set the expiry threshold to 7, 30, 60 or 90 days to suit your renewal window.
- Type the hostname you are actually serving into Hostname to test. You get a yes or no against the SAN list, the entry that matched, and wildcards applied the way browsers apply them.
- To confirm a CSR produced a certificate, paste both and open the Compare tab. The verdict compares the public keys byte for byte, so it works for EC keys as well as RSA.
- To review a renewal, compare two certificates: paste the old one and the new one, then read what changed in the SAN list, the validity, the key, and the issuer.
- In the Key tab, copy the public key as SPKI PEM, or turn the certificate to JWK, or send the key straight to the PEM and JWK converter.
Common Use Cases
The certificate on the server is not the one you deployed
Decode what you deployed, decode what the server is serving, and compare the SHA-256 fingerprints. If they differ, the load balancer or the config reload is the problem, not the certificate.
Renewal review
Old certificate on the left, new one on the right. Confirm the SAN list did not quietly lose an entry, and that the key was rotated (or deliberately was not). The comparison table lists SAN entries added and removed instead of leaving you to read two blocks of text side by side.
CSR review before it goes to a CA
Check the Common Name, the SAN list, the organization fields and the key size before you hand it over, because fixing any of them afterwards means reissuing. The same checks run against an internal-CA certificate you signed yourself, which is where the self-signed certificate and CA:TRUE findings earn their keep.
PKI plumbing
Pull the SubjectPublicKeyInfo out of a certificate as a JWK for a JWKS document, an mTLS setup, or a JWT x5c header, without shelling out to openssl and a script.
Frequently Asked Questions
Is it safe to decode a certificate online?
For a certificate or a CSR, yes, and the reason matters more than the reassurance. A certificate is public by design: a server sends it in the clear to every client that connects, so anyone who can reach your host already has a copy. A CSR carries the public half of a key pair plus the names you are asking a CA to sign. Neither is a secret. A private key is an entirely different matter, and this page detects a pasted private key and refuses to decode it rather than parsing it anyway. Parsing also runs in your browser, and nothing you paste is uploaded or stored. Open the network tab and check.
Why does my certificate work in Chrome but fail in curl or Java?
Almost always a missing intermediate. Browsers cache intermediates from earlier connections and many will also fetch one from the AIA caIssuers URL in the certificate. curl and most JVM configurations do neither, so they see a chain that stops before a trusted root and refuse it. The fix is on the server: send the leaf and every intermediate, leaf first. Paste your chain file here and the Checks tab reports missing-intermediate with the issuer name it could not find, plus the certificate chain order the file should be in.
What is the difference between Key Usage and Extended Key Usage?
Key Usage is a bit field saying what the key may do cryptographically: sign data, encipher a key, sign other certificates, sign a CRL. Extended Key Usage is a list of OIDs saying what the certificate is for: TLS server, TLS client, code signing, email. A TLS server certificate normally needs digitalSignature or keyEncipherment in Key Usage and serverAuth (1.3.6.1.5.5.7.3.1) in Extended Key Usage. If EKU is present and serverAuth is missing, clients reject the certificate for the wrong purpose even though everything else about it is fine. The full OID list is on the X.509 extension reference page.
What is the difference between SAN and Common Name?
Common Name is an attribute of the subject DN and is the legacy way a hostname was expressed. Subject Alternative Name is the extension that actually carries hostnames, and it is the only one browsers read: Chrome stopped honoring Common Name in version 58 and the other browsers followed. A certificate whose hostname appears only in the CN fails in a browser today with NET::ERR_CERT_COMMON_NAME_INVALID. The lint pass flags both cases, a missing SAN list and a CN that no SAN entry covers.
How do I check that a private key matches a certificate?
Half of that question runs here and half deliberately does not. Pasting a CSR and a certificate together answers whether the CSR matches the certificate: the Compare tab reads both SubjectPublicKeyInfo structures and compares the key bytes, which is why it is correct for EC keys as well as RSA, unlike the common openssl -modulus | md5 recipe that only handles RSA. The private-key half is not offered and will not be, because we do not want your private key. Run it locally: openssl pkey -in key.pem -pubout | openssl sha256 against openssl x509 -in cert.pem -noout -pubkey | openssl sha256, then compare the two digests.
How do I check when my SSL certificate expires?
To check a certificate expiry date, paste the certificate and read the Not after field and the countdown next to it. The countdown is computed against this machine's clock, so a machine with a wrong clock gives a wrong answer, which is also the second most common reason a certificate reads as not yet valid. The Warn at control sets the threshold for the expiring-soon finding at 7, 30, 60 or 90 days, so you can match it to whatever your renewal automation actually uses.