About this tool
Inspect bounded certificate evidence before deployment or troubleshooting while keeping supplied-chain signatures separate from trust, hostname, and revocation claims.
X.509 Certificate Decoder turns the base64 blob in a PEM file, or the raw bytes of a DER file, into a readable breakdown of who the certificate is for, who issued it, when it is valid, and what it may be used for. It reads subject and issuer names, serial number, notBefore and notAfter dates with a days-remaining badge, subject alternative names, key usages, signature and public key algorithms, key size, and every extension, then computes a SHA-256 fingerprint over the DER bytes. When you paste a full chain, it also checks whether each certificate's signature matches the issuer certificate you supplied. A findings list flags expired or not-yet-valid certificates, SHA-1 or MD5 signatures, RSA keys under 2048 bits, server certificates without SANs, and self-signed roots.
- Accepts strict CERTIFICATE PEM blocks or one exact DER sequence, rejects outside text and trailing bytes, and limits certificate, extension, and SAN counts.
- Shows subject, issuer, serial number, validity, SANs, usages, algorithms, key size, constraints, extensions, and deterministic validity or legacy-crypto findings.
- Computes SHA-256 fingerprints, verifies issuer signatures only when matching certificates are supplied, and exports a versioned scope-limited JSON report.
How to use Certificate Decoder
Drop a .pem, .crt, .cer, .der, or .txt file onto the upload area, or paste one or more BEGIN CERTIFICATE blocks into the text box and press the decode button. The parser is strict: text outside the PEM markers, or trailing bytes after a DER sequence, is rejected rather than skipped, and input is capped at 2 MB and 50 certificates. When the input holds a chain, the Certificate in supplied chain dropdown lets you switch between the leaf, intermediates, and root. The header shows a validity badge such as 87 days remaining or Expired 12 days ago, followed by the field sections and the Review findings block. Copy individual values such as the fingerprint, or download the JSON report to keep a record of what was decoded.
When this tool is useful
- Ops engineers checking which SANs a renewed certificate actually contains before swapping it into a load balancer.
- Developers debugging a TLS handshake failure who need to confirm the intermediate in their bundle really signed the leaf.
- Security teams reviewing a partner-supplied certificate for weak signature algorithms or short RSA keys before pinning it.
- Support staff reading the expiry date and issuer of a certificate a customer attached to a ticket.
- Anyone comparing a SHA-256 fingerprint shown in a browser warning against the file a vendor sent.
Practical tips
- Paste the leaf and intermediate together to get a chain-link result; a missing issuer produces an issuer-not-supplied note, not a failure, so add the intermediate for a real signature check.
- Signature verification against a supplied issuer is not trust. The tool never consults system roots, checks hostnames, or queries OCSP or CRL endpoints.
- If decoding fails on a .crt file, open it in a text editor. Some tools export DER with a .crt extension, and stray headers in PEM files must be removed.
- The days-remaining badge uses your device clock, so an expired warning on a machine with a wrong date is a false alarm.
- Self-signed shows as an informational finding, not an error. It is expected for a root or a development certificate.
Examples you can test
Load an example, compare the result with the expected output, then replace it with your own input.
Leaf and intermediate from a web server
Example input
fullchain.pem containing the site certificate followed by the Let's Encrypt R11 intermediate
Expected output
2 certificates decoded; the leaf shows SANs example.com and www.example.com, 61 days remaining, RSA 2048; the chain link reports the intermediate's signature checks out.
The root is not in the file, so the intermediate shows an issuer-not-supplied note, which is normal for server bundles.
Old internal CA certificate
Example input
internal-ca.der, a single DER-encoded certificate from 2014
Expected output
Expired finding with the day count, a legacy-signature warning for sha1WithRSAEncryption, and a self-signed note.
Two findings at once often explain a modern client refusing the certificate: age and a signature algorithm browsers no longer accept.
Validation checklist
- Confirm you are viewing the intended certificate in the chain dropdown.
- Check every hostname you serve appears in the subject alternative names.
- Review the validity badge and the notAfter date against your renewal calendar.
- Read each Review finding and decide whether it blocks deployment.
- Compare the SHA-256 fingerprint with the value from a separate trusted source.