Inputs
Example
Paste a PEM chain or fetch a public host certificate, then review SAN matching, expiry, issuer, algorithms, EKU, AIA/OCSP, CRL, policies, SCT count, fingerprints, and SPKI hashes.
SSL Certificate Decoder
Decode X.509 certificates in the browser, or fetch one public host certificate through the guarded TLS endpoint.
Use it to turn a pasted or live X.509 certificate into a practical health verdict before debugging hostname, chain, DANE, or endpoint mismatches.
What a certificate actually says
A TLS certificate is a dense bundle of claims — who the subject is, which names are covered, who vouched for it, with which algorithms, until when — and most outages caused by certificates come down to one field nobody looked at: a SAN list missing the one hostname that matters, an expiry date on a certificate everyone thought was auto-renewed, a chain that serves the leaf without its intermediate. The information is always there; it is just encoded in formats built for machines.
This decoder accepts exact CERTIFICATE PEM, certificate chains, strict Base64 DER, and strict hexadecimal DER and turns them into a readable X.509 report: version, serial, both signature-algorithm fields, subject, issuer, validity, SPKI, SAN, KU, EKU, Basic Constraints, SKI, AKI, AIA, CRL distribution points, policies, name constraints, SCT inventory, and unknown critical extensions. It can also fetch the certificate and presented chain a public implicit-TLS service is serving right now.
From PEM paste to chain reading
Paste the certificate when you have it — from a file, a ticket, an ACME log — and read the verdict and findings before diving into extensions. The SAN match against your intended hostname and the validity window resolve the majority of practical questions. Hex and base64 input exist precisely because certificates arrive in inconvenient shapes: a blob from a log pipeline decodes just as well as a tidy PEM file.
For a live question, fetch the certificate the host actually presents and compare it with what you expected to be deployed — after renewals this is the moment mismatches surface, and the chain table shows whether intermediates are being served rather than assumed. The SPKI hash output is the bridge to DANE work: it is the value TLSA records with selector 1 pin, so the decoder doubles as the fact-checking step before touching TLSA or CAA records.
Decoding versus verification
Pasted certificate material stays in the browser. Live retrieval sends host and port to /api/tls-cert.php, which resolves public DNS names only, blocks private and reserved targets, allows only common implicit-TLS/HTTPS ports, and captures the peer certificate and presented chain when OpenSSL exposes it. Hostname matching follows RFC 9525-style SAN-only identity: no Common Name fallback, IP literals match only iPAddress SANs, and a wildcard covers one complete left-most label. Chain order and issuer/subject or AKI/SKI linkage are structural evidence only; cryptographic chain signatures, a trust anchor, revocation, and CT-log inclusion are not verified.
Frequently asked questions
Which certificate does the live fetch capture?
The peer certificate the public host presents on the chosen port, plus the served chain when available. It is designed for inspecting the deployed leaf — the thing renewals and load balancers most often get wrong.
Why is decoding not the same as verification?
Decoding reads what the certificate claims. Verification decides whether to believe it — chain building, trust stores, hostname policy, revocation, and timing all participate. This tool gives you the claims and their internal consistency.
Does the decoder fall back to the certificate Common Name?
No. DNS identity is matched against dNSName SAN entries only, and IP literals only against iPAddress SAN entries. A Common Name is displayed as certificate content but never used as a successful identity fallback.
What should I check after a renewal?
Serial number and validity window to confirm the new certificate is actually being served, the SAN list against every name in use, and the chain table for missing intermediates — the three renewal classics, in that order.
Why are SPKI hashes shown?
Because the SubjectPublicKeyInfo hash is what key-based pinning uses — DANE TLSA records with selector 1 in particular. Reading it here means the value you publish elsewhere is derived from the certificate, not transcribed by hand.
Why is a SHA-1 fingerprint still displayed?
Purely as an identifier: plenty of operational systems still reference certificates by SHA-1 fingerprint. Its presence is for cross-referencing, not an endorsement of SHA-1 for any cryptographic purpose.
Can it inspect internal or private hosts live?
No. The live endpoint accepts public DNS names on a small set of TLS ports. For internal systems, export the certificate and use the paste path — the analysis is the same.