X.509 certificate decoder

What is an X.509 certificate?

X.509 is the ITU-T standard for public-key certificates, profiled for the Internet PKI by RFC 5280. An X.509 certificate binds a public key to an identity — a hostname, email address, or organization — and is signed by a Certificate Authority. Every HTTPS connection, code-signed installer, S/MIME email, and mTLS handshake involves at least one X.509 certificate being parsed and verified.

The certificate plus the chain of CAs above it is what HTTPS, S/MIME, mTLS, and code-signing all rely on to answer the question “is this public key really controlled by who claims it?”. A relying party walks that chain up to a root it already trusts; the binding only holds if every signature in the chain validates and every intermediate is within its validity window and not revoked.

How it works

A certificate is ASN.1 DER-encoded binary, almost always wrapped in a PEM container — -----BEGIN CERTIFICATE-----, base64, -----END CERTIFICATE-----. Fields include the subject (the entity), issuer (the CA), validity bounds notBefore and notAfter, and the subject's public key.

Extensions carry most of the meaning. Subject Alternative Name (SAN) lists the hostnames a TLS cert is valid for; modern browsers ignore the legacy Common Name field entirely. Key Usage and Extended Key Usage (serverAuth, clientAuth, codeSigning) constrain what the certificate may do. Authority Information Access points to the issuer cert and the OCSP responder for revocation checks.

When to use this tool

• Diagnosing a TLS error — expired cert, hostname mismatch, missing intermediate.
• Inspecting a freshly issued cert to confirm its SAN list before deploying it.
• Reviewing a client cert during mTLS troubleshooting.
• Decoding a code-signing or S/MIME certificate to check Extended Key Usage and validity.
• Reading a self-signed cert your platform team handed you to confirm what it covers.

Common pitfalls

• Common Name has been deprecated for hostname matching since 2017. Modern clients only check SAN. A cert with the right CN but no matching SAN entry fails in the browser.
• Servers often send only the leaf certificate and forget the intermediate. Browsers cache common intermediates; less-common clients (curl, Java, mobile apps) fail with “unknown issuer”.
• Validity and revocation are independent. A cert inside its notBefore/notAfter window can still be revoked via CRL or OCSP.
• Self-signed is not inherently insecure — it just means the trust model is “the operator shipped the cert manually”. Production-facing endpoints should still use a publicly trusted CA.
• PEM and DER are different envelopes around the same data. A DER file pasted into a tool expecting PEM will not parse.

Frequently asked

Why does my browser say the certificate is invalid?

Most often: the hostname is not in the SAN list, the cert has expired, the chain is incomplete, or the certificate is revoked.

What are SANs?

Subject Alternative Names — the list of hostnames (or IPs, or email addresses) the cert is valid for. A cert with SAN example.com, www.example.com covers both names; one with only example.com does not cover the www subdomain.

What is the difference between PEM and DER?

DER is the raw binary ASN.1 encoding. PEM is DER base64-encoded and wrapped in BEGIN/END markers. They carry the same data.

Do I need to include intermediate certificates?

Yes, on the server side. Send the leaf plus any intermediates leading toward (but not including) the publicly trusted root. Forgetting the intermediate is the most common “works in Chrome but not in curl” failure.

What is OCSP stapling?

The server fetches and attaches a fresh signed revocation-status response from the CA, so the client does not have to make a separate OCSP query at handshake time.