Introduction
TLS certificates are X.509 ASN.1 structures that most developers never inspect directly. You paste one into nginx, hit a browser error, and stare at a vague message about a name mismatch or an expired chain. This decoder parses the certificate in your browser with node-forge and shows every field: subject, issuer, validity window, serial number, public key, signature algorithm, extensions, and fingerprints. Paste a PEM block, drop a .crt file, or paste hex DER, and the decoded output appears instantly. No upload, no server round trip.
What this tool does
- Parse X.509 certificates from PEM, base64 DER, or hex DER input, or by uploading a .pem, .crt, or .der file directly
- Display the subject and issuer distinguished names with each attribute (CN, O, OU, C, ST, L) on its own line
- Show the version, serial number, validity period (not before, not after), and a live validity status badge (valid, expired, or not yet valid)
- Extract the public key details: RSA modulus length in bits and public exponent, or the EC curve name for ECDSA keys
- List the signature algorithm (by OID name), signature length, and all X.509 extensions including Subject Alternative Names, Basic Constraints, and Key Usage with criticality flags
- Compute SHA-256 and SHA-1 fingerprints of the DER-encoded certificate for comparison against pinning lists or CA transparency logs
How this tool works
The tool uses node-forge's `certificateFromPem` to parse the input. If you paste a PEM block (text starting with `-----BEGIN CERTIFICATE-----`), it passes it directly to the parser. If you paste hex DER, it converts the hex to bytes, base64-encodes them, wraps them in PEM headers, and parses. If you paste base64 DER without headers, it wraps and parses the same way. File uploads are read as text for PEM files or as an ArrayBuffer for binary DER, then converted to the same PEM wrapper.
Once parsed, the tool walks the certificate object and formats each field. The subject and issuer are iterated as attribute lists, printing `name: value` for each RDN component. The validity check compares `notBefore` and `notAfter` against the current time and shows a badge: green for currently valid, red for expired, amber for not yet valid.
For the public key, the tool checks for `n` and `e` properties (RSA) and reports the modulus bit length and exponent. For EC keys it prints the curve name. The extensions array is iterated to list every extension with its name or OID and a critical / non-critical flag. Subject Alternative Names are extracted separately and labeled by type (DNS, IP, email, URI). Finally, the tool re-serializes the certificate to DER and computes SHA-256 and SHA-1 fingerprints. Everything runs client-side.
How X.509 certificates work (RFC 5280, ITU-T X.509)
X.509 is the ITU-T standard for public key certificates, defined in ITU-T X.509. The Internet profile is specified in RFC 5280, which constrains the format and defines how extensions like Subject Alternative Name, Basic Constraints, and Key Usage are interpreted.
A certificate is an ASN.1 SEQUENCE containing a `tbsCertificate` (to-be-signed), a `signatureAlgorithm`, and a `signatureValue`. The `tbsCertificate` contains version, serial number, signature algorithm, issuer name, validity period, subject name, subject public key info, and optional extensions. The issuer signs the DER encoding of `tbsCertificate` with its private key, producing `signatureValue`.
Certificate chains work by linking: the server certificate is signed by an intermediate CA, the intermediate is signed by a root CA, and the root is self-signed and pre-installed in the trust store. During a TLS handshake (RFC 8446 for TLS 1.3), the server sends its certificate chain. The client verifies each signature up to a trusted root, checks validity windows, and confirms that a Subject Alternative Name matches the requested hostname. The SAN extension (RFC 5280 section 4.2.1.6) is the authoritative source for hostnames; the Common Name field is legacy and ignored by modern browsers. Basic Constraints marks whether a certificate is a CA, and Key Usage restricts what the key may be used for.
How to use this tool
- Paste a PEM certificate (including the BEGIN and END lines) into the input area. Alternatively, paste base64 DER or hex DER, or click Upload to load a .pem, .crt, or .der file
- The tool auto-detects the input format and parses the certificate with node-forge. The decoded fields appear in the output panel immediately
- Check the subject and issuer sections to confirm the certificate belongs to the expected entity and was issued by the expected CA
- Review the validity status badge. If it says Expired or Not yet valid, the certificate will fail TLS validation regardless of other fields
- Inspect the public key section for the key type and size. RSA keys below 2048 bits are deprecated; EC keys should use P-256 or stronger curves
- Scroll to the extensions section to verify Subject Alternative Names match your hostnames, and that Basic Constraints and Key Usage are appropriate for the certificate's role
- Compare the SHA-256 fingerprint against your pinning list or a CT log entry to confirm you are looking at the exact certificate you expect
Real-world examples
Debugging a hostname mismatch error
A browser shows `NET::ERR_CERT_COMMON_NAME_INVALID` for a site. Paste the server's PEM certificate into the tool. The Subject Alternative Names section lists `DNS: old-domain.com` but the site is now served from `new-domain.com`. The SAN does not cover the new hostname, so TLS validation fails. The fix is to reissue the certificate with the correct SANs, not to change the Common Name.
Verifying a certificate chain from a TLS handshake
You capture a server certificate and its intermediate during a TLS 1.3 handshake. Paste the server certificate: the issuer field shows `CN=Let's Encrypt R3, O=Let's Encrypt, C=US`. Paste the intermediate: its subject matches that issuer, and its issuer shows `CN=ISRG Root X1`. The root is self-signed and in your trust store. Each signature verifies and all validity windows are current, so the chain is valid.
Checking an expired certificate
A service stops accepting TLS connections. Paste the certificate and the validity status badge turns red with `EXPIRED`. The Not After field shows a date in the past. The tool also shows the signature algorithm (e.g. `sha256WithRSAEncryption`) and key size, so you can generate a replacement with the same parameters using the CSR Generator.
Comparison with similar methods
| Method | Complexity | Typical use |
|---|---|---|
| PEM (RFC 7468) | Base64 DER with text headers | Config files, nginx, Apache, email attachments |
| DER (X.690) | Raw binary ASN.1, no encoding overhead | Java keytool, hardware appliances, TLS wire format |
| PKCS#7 / CMS (RFC 5652) | Wrapper for one or more certificates + signatures | S/MIME, certificate chain bundles (.p7b) |
| PKCS#12 (RFC 7292) | Encrypted bag with key + certificate + chain | Windows IIS, Java keystores (.pfx, .p12) |
| OpenSSL text dump | Human-readable, verbose, command-line only | openssl x509 -text -noout for local inspection |
Limitations or considerations
This tool decodes a single certificate. It does not verify the signature against an issuer's public key, build or validate a full chain, or check revocation status via OCSP or CRL. For chain validation and revocation checking, use the Certificate Analyzer.
The tool does not parse certificate signing requests (CSRs). For inspecting a CSR before submitting it to a CA, use the CSR Generator. It also does not parse private keys embedded in PKCS#12 files; those require a password and a different parser.
node-forge's certificate parser handles RSA and EC public keys. It may not display Ed25519 or Ed448 key details correctly, because those use a different SubjectPublicKeyInfo structure. If the public key section shows `Unknown`, the certificate likely uses an algorithm node-forge does not fully support.
The SHA-1 fingerprint is provided for compatibility with older pinning lists. SHA-1 is collision-broken and should not be used for new security decisions. Use the SHA-256 fingerprint instead.
Frequently asked questions
What is the difference between Subject Alternative Name and Common Name?
Subject Alternative Name (SAN) is the authoritative list of hostnames a certificate covers, defined in RFC 5280 section 4.2.1.6. Common Name (CN) is a legacy field that browsers once checked but now ignore. Modern certificates must list all hostnames in the SAN extension. If a hostname is in the CN but not in the SAN, the certificate will fail validation in Chrome, Firefox, and Safari.
Why does the tool show a validity status badge?
The badge compares the current time against the certificate's `notBefore` and `notAfter` fields. If the current time is after `notAfter`, the certificate is expired and TLS clients will reject it. If before `notBefore`, it is not yet valid. The badge updates live.
Can this tool verify a certificate chain?
No. This tool decodes a single certificate and displays its fields. It does not verify the issuer's signature on the certificate, check revocation status, or build a chain to a trusted root. For chain validation, use the Certificate Analyzer, which checks signature verification and path building.
What is a certificate fingerprint and how do I use it?
A fingerprint is a hash of the DER-encoded certificate. The tool computes SHA-256 and SHA-1 fingerprints. You compare a fingerprint against a known-good value to confirm you are looking at the exact same certificate, byte for byte. This is used in Certificate Transparency log entries to match a certificate to a log record.
Does the tool support Ed25519 certificates?
The tool parses the certificate structure and displays subject, issuer, validity, and extensions. However, node-forge's public key handler may not recognize Ed25519 keys correctly, because Ed25519 uses a different SubjectPublicKeyInfo structure defined in RFC 8410. The public key section may show `Unknown` for these certificates. All other fields will display normally.
Conclusion
X.509 certificates are the backbone of TLS trust, but their ASN.1 structure makes them opaque without a parser. This decoder shows every field in a certificate so you can debug hostname mismatches, verify validity windows, inspect SANs, and compare fingerprints without installing OpenSSL. For generating a new certificate signing request, use the CSR Generator. For chain validation and revocation checking, see the Certificate Analyzer. To inspect the private key that pairs with a certificate, use the PEM Key Parser.