SSL Certificate, CSR & Chain Decoder

What is in an X.509 certificate

An X.509 certificate — the kind behind every SSL/TLS connection — binds a public key to an identity (the subject) and is itself signed by another certificate's private key (the issuer). It carries the subject and issuer names, a serial number, a validity window, the public key and its type, a signature, and a set of extensions — Subject Alternative Names (SANs), key usage flags, basic constraints, and identifiers that link a chain together. This online decoder reads every one of those fields from the raw DER bytes with a hand-written parser, not a generic library, so a field that is malformed or unusual is reported specifically rather than silently mis-read.

PEM, DER, .crt, .cer and .pem — which formats work

Most certificate files are PEM: base64 text between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----. A .pem, .crt or .cer file that opens as readable text in an editor is PEM — paste its contents here. Several blocks in one paste, such as a Let's Encrypt fullchain.pem or an Apache SSLCertificateChainFile, are decoded as a chain. Base64 with no BEGIN line at all — the way a Kubernetes Secret stores tls.crt — is accepted too. Indentation copied from a YAML file is stripped, and a body whose length is not a multiple of four is reported as truncated with the exact count. A binary DER file is not accepted as a file yet; convert it with openssl x509 -inform der -in cert.der -out cert.pem and paste the result. A PKCS#7 (.p7b) bundle is named for what it is rather than mis-parsed, and this page does not read it yet. PKCS#12 (.pfx, .p12) is out of scope entirely — it contains a private key, and this page will never ask for its password.

Expiry, key size and signature algorithm

The Summary tab shows the validity window and the days remaining, computed against your device's clock and labelled as such — an expired certificate and a not-yet-valid one are reported separately, because they have different causes. The Key tab shows what the public key actually is: for RSA the modulus size in bits (2048, 3072, 4096) and the exponent, for ECDSA the named curve — prime256v1 (P-256), secp384r1 (P-384) or secp521r1 (P-521) — and for Ed25519 or Ed448 the algorithm itself, since those carry no parameters. The signature algorithm is shown next to it: a SHA-1 signature is flagged as cryptographically broken even when it verifies, and an MD5 one is reported as not checkable in a browser rather than treated as ordinary.

Fingerprint, thumbprint, serial number and SPKI pin

The SHA-256 fingerprint — Windows calls the same value the thumbprint — is the hash of the entire DER-encoded certificate, printed colon-separated in uppercase to match openssl x509 -fingerprint -sha256 and the Windows certificate viewer, with SHA-1 alongside for older tooling. The serial number is shown as hex exactly as OpenSSL prints it, including any leading zero byte, so the string you copy into a revocation form or a support ticket is byte-for-byte what the CA issued. The SPKI pin is a different value over different bytes: the SHA-256 of the public key alone, base64-encoded, which is what pin-sha256, HPKP and mobile certificate-pinning configs expect. Every one of them has a copy button, and each is labelled with what it hashes so the two are never confused.

CN vs SAN, and why a certificate with only a CN fails

Older certificates put a hostname in the subject's Common Name (CN). Since RFC 2818 was superseded, every current browser matches only the Subject Alternative Name extension — a certificate with a CN and no matching SAN is not valid for any hostname, no matter how the CN reads. This is a real, common deployment failure, and this tool flags it explicitly rather than leaving you to notice a missing extension yourself.

Decoding a CSR (certificate signing request)

A CSR is what you send to a certificate authority to get a certificate issued. Paste a -----BEGIN CERTIFICATE REQUEST----- block — or the -----BEGIN NEW CERTIFICATE REQUEST----- form that Windows and IIS produce — and the decoder shows the subject, the requested SANs, and the key type and size. Those SANs live in an extensionRequest attribute nested two levels deeper than in a certificate, which is why "my SANs disappeared" is such a common CSR complaint: many viewers never look there. A CSR's signature proves only that whoever made it holds the matching private key — not who they are, and not that any CA will issue for it. A CSR has no issuer and no expiry, and this page says so instead of rendering empty rows.

Checking the certificate chain: leaf, intermediate, root

A server usually presents more than one certificate: the leaf (yours), one or more intermediates, and sometimes the root. The conventional order is leaf first, each certificate signed by the next. If you paste a bundle in a different order, this tool says so rather than silently reordering it — the point is to describe the chain exactly as your server would send it, because "I reordered it and it works" answers a different question than a failing handshake is asking.

What we check, and what we cannot

For each adjacent pair in a pasted chain, this tool checks three separate things: does the issuer's name match, does the issuer's public key actually verify the signature (via crypto.subtle.verify), and does the Authority/Subject Key Identifier hint line up. A name match with a failed signature usually means the wrong intermediate came from the right CA — a real, otherwise-baffling failure this tool is specifically good at showing. We do not check the certificate against any trust store — the result says "signed by the certificate above it", never "trusted" — and we do not check revocation (OCSP/CRL), because neither is reachable from a browser. Distribution-point URLs are shown as read, never contacted.

Why you should not paste a private key anywhere

A private key is the one artifact that must never leave the machine it lives on. This page checks the raw text you paste for private-key armour before any parsing happens at all — not after, not on a server — and if it finds one, it refuses to read it and clears the box. That check runs whether or not this page is trustworthy, and the same caution should apply to every other page you might be tempted to paste a key into.

The OpenSSL equivalents

Everything here mirrors a command you can run offline:

• openssl x509 -in cert.pem -text -noout — decode a certificate
• openssl x509 -in cert.pem -noout -fingerprint -sha256 — the SHA-256 fingerprint
• openssl x509 -inform der -in cert.der -out cert.pem — convert DER to PEM
• openssl req -in req.csr -text -noout — decode a CSR
• openssl s_client -connect example.com:443 -showcerts — fetch a live server's chain to paste here
• openssl verify -untrusted chain.pem cert.pem — check a chain against a trust store, which this page does not do