Certificate Decoder

About this tool

X.509 certificates underpin TLS/SSL, code signing, and identity verification across the internet. This inspector lets you paste a PEM certificate or a raw base64 DER block and see a structured breakdown: Subject and Issuer (CN, O, OU, C, ST, L), validity dates with a days-remaining count, Subject Alternative Names (DNS names, IP addresses and email addresses), the RSA key size, the signature algorithm as an OID (for example 1.2.840.113549.1.1.11 for SHA-256 with RSA), the serial number, and SHA-1 and SHA-256 fingerprints. Certificates expiring within 30 days get an orange banner and expired ones a red banner. Copy as JSON exports the decoded fields. Parsing uses node-forge 1.3.1, downloaded from jsDelivr on first use and run in your browser. node-forge only reads RSA keys, so ECDSA and Ed25519 certificates — including many current Let's Encrypt certificates — fail with “Cannot read public key. OID is not RSA.”

Why use it

• No openssl binary needed for RSA certificates — inspect them directly in any modern browser.

• Expiry countdown highlights certificates expiring within 30 days with a colored warning banner.

• Shows DNS, IP and email SANs, critical for checking wildcard coverage and multi-domain certificates.

• JSON export enables pasting certificate metadata into reports or scripts without reformatting.

• Certificate data is parsed in your browser and never uploaded.

How to use

1. Copy a PEM certificate block (from a .crt/.pem file, openssl s_client output, or a CI artifact) and paste it into the input area.
2. Alternatively paste a raw base64 DER certificate without the -----BEGIN/END----- headers; the tool treats any input without BEGIN CERTIFICATE as DER.
3. Click Inspect Certificate to decode all fields.
4. Review the table showing Subject, Issuer, SANs, validity dates, key info, serial number and fingerprints.
5. Use the Copy as JSON button to export the decoded data for scripting or documentation.
6. If you see “OID is not RSA”, the certificate uses an ECDSA or Ed25519 key; inspect it with openssl x509 -text instead.

When it helps

• Debugging TLS handshake failures by verifying certificate Subject and SAN fields before deployment.
• Checking that a newly-issued certificate covers all required domains via the SAN list.
• Reviewing RSA certificates in a CA bundle or certificate store export.
• Verifying certificate fingerprints before pinning them in a mobile app.
• Monitoring expiry dates on certificates that lack automated renewal.

Examples

-----BEGIN CERTIFICATE-----
(RSA 2048 certificate for api.example.com)
-----END CERTIFICATE-----

Subject: CN=api.example.com, O=Example Inc
SANs: DNS: api.example.com
Key Type: RSA 2048 bit
Signature Algorithm: 1.2.840.113549.1.1.11
Valid Until: … (N days remaining)
SHA-1 / SHA-256 Fingerprint: colon-separated hex

(PEM block of a Let's Encrypt ECDSA P-256 certificate)

Parse error: Cannot read public key. OID is not RSA.

(PEM block of an RSA certificate expiring in 12 days)

Orange banner: Expiring soon: 12 days remaining

Click Copy as JSON after inspecting an RSA certificate.

{
  "subject": "CN=api.example.com, O=Example Inc",
  "issuer": "CN=…",
  "validFrom": "…",
  "validUntil": "…",
  "daysUntilExpiry": 53,
  "subjectAltNames": ["DNS: api.example.com"],
  "keyType": "RSA 2048 bit",
  "sigAlgorithm": "1.2.840.113549.1.1.11",
  "serialNumber": "…",
  "sha1Fingerprint": "…",
  "sha256Fingerprint": "…"
}

Tips

• The SHA-256 fingerprint in the output can be compared against the value shown in browser DevTools under Security > Certificate to confirm you are inspecting the same cert the browser sees.
• Certificates expiring in under 30 days show an orange banner — export the JSON and add a row to your monitoring spreadsheet or alerting system.
• For wildcard certificates, check the SAN list carefully — *.example.com does NOT cover example.com itself unless it is also listed as a separate SAN entry.
• Multi-SAN certs are common — verify every required domain appears in the SAN list before deploying, because missing domains will cause a NET::ERR_CERT_COMMON_NAME_INVALID in users' browsers.
• Paste one certificate at a time; with a full chain pasted, only the first certificate is decoded and the fingerprints are computed over the whole paste.
• When pinning a fingerprint in a mobile app, prefer SHA-256 over SHA-1 — modern pinning libraries (TrustKit, Network Security Config) all support SHA-256 and SHA-1 is collision-prone.

Frequently Asked Questions

Glossary

PEM

Privacy Enhanced Mail — the base64-encoded form of a DER certificate surrounded by -----BEGIN CERTIFICATE----- / -----END CERTIFICATE----- headers, used in most server config files.

DER

Distinguished Encoding Rules — the binary ASN.1 encoding of an X.509 certificate. PEM is just DER base64-encoded with header lines added.

ASN.1

Abstract Syntax Notation One — the schema language used by X.509 to define certificate structure. ASN.1 is the underlying grammar; DER is one of its binary encodings.

SAN (Subject Alternative Name)

An X.509 extension listing all hostnames and IPs a certificate is valid for. Modern browsers require at least one SAN entry and ignore the Subject CN.

Key Usage

An X.509 extension that restricts what operations a certificate's public key may perform — digital signature, key encipherment, certificate signing, CRL signing, etc.

CA (Certificate Authority)

An entity that issues and signs certificates after verifying the requester's identity. Public CAs (Let's Encrypt, DigiCert, Sectigo) are trusted by browsers; private CAs serve internal use.

Fingerprint

A cryptographic hash (typically SHA-1 or SHA-256) of the entire certificate DER binary, used for identification, pinning, and out-of-band identity verification.

CN (Common Name)

A field in the X.509 Subject that historically identified the domain. Modern TLS relies on the SAN extension instead — CN is now mostly informational.