# X.509 Certificate Decoder

> Paste a PEM, base64, or hex certificate to read its subject, issuer, validity window, public key, and v3 extensions, with SHA-256 and SHA-1 fingerprints. Runs entirely in your browser.

- Tool: https://ronutz.com/en/tools/x509
- Family: Certificates & PKI

---

## What it does

Paste a certificate in PEM, base64, or hex and the tool decodes it: the subject and issuer, the validity window, the public key, and the v3 extensions, together with SHA-256 and SHA-1 fingerprints. It parses the certificate entirely in your browser and contacts nothing.

## What an X.509 certificate holds

An X.509 certificate binds a public key to an identity, signed by a certificate authority. Its main body, the TBSCertificate ("to be signed"), carries the fields the CA vouches for: the version and serial number, the issuer and subject distinguished names, the validity window (`notBefore` and `notAfter`), the subject's public key, and a set of extensions; the CA's signature over that body is what makes the whole thing trustworthy. The tool walks the DER-encoded ASN.1 (the tag-length-value encoding defined by X.690) into readable fields, and renders distinguished names most-specific-first in the RFC 4514 style.

## The v3 extensions that matter

Most of what makes a modern certificate useful lives in its v3 extensions, and the decoder surfaces the important ones:

- **Subject Alternative Names**, the list of hostnames the certificate is actually valid for (the subject common name is legacy for this purpose);
- **Key Usage** and **Extended Key Usage**, which constrain what the key may do, such as server authentication;
- **Basic Constraints**, which says whether the certificate is a CA and may sign others;
- **Authority Information Access**, from which the OCSP responder location (RFC 6960) is surfaced; and
- the **TLS Feature** extension, whose `status_request` flag is the Must-Staple marker (RFC 7633).

For elliptic-curve keys, the named curve (P-256, P-384, or P-521) is read from the key info per RFC 5480.

## Fingerprints

A fingerprint is a hash of the certificate's raw DER bytes, and it uniquely identifies that exact certificate, which is what certificate pinning and many tools compare on. The tool shows the SHA-256 fingerprint, the current standard, and the SHA-1 fingerprint, still common in older tooling despite SHA-1's weakness for collisions.

## Using it

Paste a certificate as PEM, base64, or hex and read its subject, issuer, validity, key, and extensions, with both fingerprints. The decode is deterministic; whether the certificate is expired right now is shown separately, against your device clock.

## Standards and references

- [RFC 5280 - Internet X.509 PKI Certificate and CRL Profile](https://www.rfc-editor.org/rfc/rfc5280) - TBSCertificate fields, validity, standard v3 extensions
- [ITU-T X.690 - ASN.1 encoding rules (BER, CER, DER)](https://www.itu.int/rec/T-REC-X.690) - DER tag-length-value encoding the parser walks
- [RFC 4514 - String Representation of Distinguished Names](https://www.rfc-editor.org/rfc/rfc4514) - the most-specific-first DN one-line rendering
- [RFC 5480 - Elliptic Curve Cryptography Subject Public Key Info](https://www.rfc-editor.org/rfc/rfc5480) - named-curve OIDs (P-256/P-384/P-521) in the key info
- [RFC 6960 - X.509 Internet PKI Online Certificate Status Protocol](https://www.rfc-editor.org/rfc/rfc6960) - OCSP responder location, surfaced from Authority Information Access
- [RFC 7633 - X.509 TLS Feature Extension (Must-Staple)](https://www.rfc-editor.org/rfc/rfc7633) - the TLS Feature extension and the status_request (Must-Staple) flag

## Related reading

- [ACME on BIG-IP: from DevCentral scripts to a native client](https://ronutz.com/en/learn/bigip-acme-certificate-automation.md): How Let's Encrypt and other ACME certificate automation works on F5 BIG-IP: the native ACMEv2 client introduced in BIG-IP 21.1.0 (provisioning, renewal, and deployment for any ACMEv2 CA), the community dehydrated-based solutions that came before it, BIG-IQ's centralized Let's Encrypt CA management profile, and where the shared ACME concepts and rate limits fit.
- [ACME on FortiGate: a built-in client for the box's own certificate](https://ronutz.com/en/learn/fortigate-acme-certificate-automation.md): How FortiOS's native ACME support obtains and renews a Let's Encrypt certificate for the FortiGate itself: the public-IP and FQDN requirements, the single-name SAN constraint, the TLS-ALPN-01 and HTTP-01 challenges (and which FortiOS versions support them), the GUI and CLI configuration, and how this differs from BIG-IP's native client.
- [ACME: how certificates issue and renew themselves](https://ronutz.com/en/learn/acme-protocol.md): How the ACME protocol automates certificate issuance end to end: the account, the order, the three challenge types, the dns-01 record you publish, and the finalize-and-download step that produces the certificate.
- [Anatomy of an X.509 Certificate](https://ronutz.com/en/learn/x509-anatomy.md): What lives inside a TLS certificate, how the ASN.1/DER bytes are structured, what the v3 extensions actually control, and why decoding a certificate is not the same as trusting it.
- [Authority Information Access: The OCSP and CA Issuers URLs](https://ronutz.com/en/learn/authority-information-access.md): The AIA extension carries two kinds of pointer: where to ask whether a certificate is revoked (OCSP) and where to fetch the issuer's own certificate (CA Issuers). What each is for, why they are easy to confuse, and what the inspector shows.
- [Certificate revocation: CRL, OCSP, and short-lived certificates](https://ronutz.com/en/learn/certificate-revocation.md): Why a certificate sometimes needs to be cancelled before it expires, why the classic revocation systems work poorly, and why the industry is shrinking certificate lifetimes instead.
- [Certificate signing requests and how certificates are issued](https://ronutz.com/en/learn/certificate-signing-request.md): What a CSR contains, why your private key never leaves your machine, how a CA validates and issues, and how ACME automates the whole exchange.
- [FortiGate SSL Inspection: Certificate vs Deep Inspection](https://ronutz.com/en/learn/fortinet-ssl-inspection-modes.md): A FortiGate inspects encrypted traffic in one of two modes: certificate inspection reads only the SNI and the certificate to make a filtering decision without decrypting, while deep (full) inspection is a full man-in-the-middle that decrypts, inspects, and re-encrypts. This maps FortiGate's SSL/SSH inspection profiles onto the generic forward-proxy interception model and covers the flow-versus-proxy engine split that shapes what each can do.
- [How certificate validation actually works](https://ronutz.com/en/learn/certificate-validation.md): The steps a client runs to decide a certificate is trustworthy: building the chain, checking signatures and dates, matching the name, and enforcing constraints.
- [Inbound TLS: Offload, Bridging, and Passthrough at the Reverse Proxy](https://ronutz.com/en/learn/tls-reverse-proxy-inbound.md): A reverse proxy handling inbound HTTPS has three choices for the TLS session: terminate it and send plaintext to the backend (offload), terminate and re-encrypt to the backend (bridging), or forward the encrypted bytes untouched (passthrough). Each trades visibility against confidentiality and cost differently. This explains all three, why the proxy holds the server's certificate, and what SNI and mutual TLS change.
- [Let's Encrypt: the free CA and its rate limits](https://ronutz.com/en/learn/lets-encrypt.md): What Let's Encrypt is, why its certificates are short-lived, and how its rate limits actually work: the per-registered-domain and per-account limits, the exact-set and authorization-failure limits, and why ARI renewals are exempt from all of them.
- [Netskope: Cloud Forward Proxy and Inline TLS Decryption](https://ronutz.com/en/learn/netskope-inline-tls-decryption.md): Netskope is a forward proxy that lives in the cloud rather than on a box at your edge: traffic is steered to its NewEdge data planes, where the Next Gen SWG decrypts, inspects, and applies policy inline. This maps Netskope's steering methods and its SAML-based user identification onto the generic forward-proxy interception model, and covers the root-CA trust requirement and the certificate-pinning bypass that every cloud-proxy deployment hits.
- [OCSP Must-Staple: Closing the Soft-Fail Gap](https://ronutz.com/en/learn/ocsp-must-staple.md): Real-time OCSP checking has a fatal weakness: when the responder is unreachable, clients usually proceed anyway. OCSP stapling and the Must-Staple flag are the fix. What the TLS Feature extension declares, and the operational risk it carries.
- [PEM, DER, and the certificate file formats](https://ronutz.com/en/learn/certificate-formats.md): Why the same certificate comes in so many file shapes, what PEM and DER actually are, and what .crt, .pem, .pfx, and .p12 really hold.
- [SSL Forward Proxy: How Outbound TLS Interception Works and What Breaks It](https://ronutz.com/en/learn/ssl-forward-proxy-interception.md): To inspect encrypted outbound traffic, a forward proxy performs a controlled man-in-the-middle: it terminates the user's TLS session, opens its own to the real server, and forges a certificate for that server signed by a private CA the organization's own devices trust. This explains the mechanics, the trust model that makes it safe (and dangerous), and why pinning, HSTS, and mutual TLS defeat it.