X.509 PEM Certificate Parser — SSL/TLS Cert Inspector & Validity Checker

Certificates sit at the top of the infrastructure trust hierarchy

An X.509 PEM certificate carries the public key that backs TLS — and the private key paired with it lets anyone decrypt the encrypted traffic of a server or impersonate it entirely. Even without the private key, a certificate file reveals Subject and SAN domain names, issuing CA, validity window, fingerprints, and Key Usage flags. For an internal PKI issuing client certificates, the Subject CN/OU can expose employee names, department names, or system identifiers that belong firmly inside the trust boundary.

The riskier mistake is accidentally including the private key. PEM bundles used by nginx, HAProxy, and similar servers often concatenate the certificate and the -----BEGIN RSA PRIVATE KEY----- or -----BEGIN OPENSSH PRIVATE KEY----- block in one file. Pasting that bundle into an online decoder sends both to a remote server. Closing the browser tab afterwards does not undo the disclosure.

Why online certificate decoders are the wrong environment for this job

Certificate inspection sites are popular precisely because the PEM format is not human-readable at a glance. The same properties that draw users there — convenience, no local tooling required — also mean the operator receives the full PEM payload in plaintext on their server. Whether inputs are logged, forwarded to analytics pipelines, or retained for any period is invisible from the user’s side. Some terms of service explicitly grant the operator a licence to use submitted data for service improvement.

The structural problem is timing: you find out what was in the bundle after you decode it, not before you paste it. When the decoded view reveals a private-key block that you meant to leave out, the key is already on the remote server. Building a default workflow that keeps PEM inspection local eliminates that race entirely.

What @peculiar/x509 and Web Crypto API do inside the browser

This tool Base64-decodes the PEM armor back to DER bytes and hands the ASN.1 structure to @peculiar/x509 (MIT licence) for parsing. OID decoding, SAN entry-type classification (DNS / IP / Email / URI), Key Usage bitfield interpretation, Basic Constraints CA flag extraction, and SKI/AKI byte extraction all execute client-side. SHA-1 and SHA-256 fingerprints are computed by the browser’s own Web Crypto API (crypto.subtle.digest) — no additional dependencies involved.

All processing stays in page memory. Open DevTools Network while you paste and click Parse: no outbound requests appear. The tool also detects -----BEGIN PRIVATE KEY----- and similar private-key headers and aborts with an error rather than processing them, so there is no path through which a private key could be quietly processed and inadvertently cached or surfaced.

A checklist to run before you deploy or distribute a certificate

Before installing a TLS certificate on a server or distributing a client certificate, use this tool to verify that the SAN DNS entries match the intended hostnames, the validity window is correct, and the Key Usage / Extended Key Usage flags match the purpose (serverAuth for a web server, clientAuth for mutual TLS). Catching a SAN mismatch or an expired certificate here costs nothing; catching it in production during an incident costs a lot. Copy the fingerprint from the output directly into your inventory or monitoring tool — one click, no manual transcription error. To inspect a JWT signed by the same certificate, jwt-decode handles the claim view and jwt-verify the signature check.

PEM, DER, ASN.1, and the X.509 v3 extension model

PEM (RFC 7468) is the Base64 textual armor wrapping DER bytes between -----BEGIN ...----- and -----END ...----- lines. The DER payload follows ITU-T X.690 Distinguished Encoding Rules — a nested Tag-Length-Value (TLV) structure. RFC 5280 defines the certificate ASN.1: Certificate ::= SEQUENCE { tbsCertificate, signatureAlgorithm, signature }, with the tbsCertificate containing Subject and Issuer Name fields (each an RDNSequence), a Validity window, a SubjectPublicKeyInfo block, and the v3 extension list.

The SAN this tool surfaces comes from extension OID 2.5.29.17 (id-ce-subjectAltName), whose GeneralName choice carries dNSName, iPAddress, rfc822Name, and uniformResourceIdentifier entries that the parser classifies by tag. KeyUsage (OID 2.5.29.15) packs flags like digitalSignature, keyEncipherment, and keyCertSign into a bit string; ExtendedKeyUsage (OID 2.5.29.37) is a sequence of OIDs such as serverAuth (1.3.6.1.5.5.7.3.1) and clientAuth (1.3.6.1.5.5.7.3.2). BasicConstraints with cA = TRUE marks an intermediate or root CA; otherwise (or when the extension is absent) the certificate is an end-entity leaf.

CA/Browser Forum Baseline Requirements and field pitfalls

Publicly trusted TLS certificates follow the CA/Browser Forum Baseline Requirements. Since September 2020 the maximum validity is 398 days; anything longer must be from a private PKI or pre-dates the change. Industry discussion in 2024–2025 has pointed toward further shortening (200-day and then 100-day caps are under consideration), so long-fixed renewal cycles are increasingly unsafe to assume. Let’s Encrypt has always issued 90-day certificates, which is why ACME-based automation dominates that ecosystem.

Common operational mistakes the parser helps catch: (1) a SAN list that includes www.example.com but not the bare example.com, breaking the apex; (2) a wildcard *.example.com that does not match a.b.example.com because wildcards only cover one label; (3) a server configuration that omits intermediate certificates, producing an unknown issuer warning in clients; (4) a chain that still uses SHA-1 signatures, which modern browsers and Java releases reject. By comparing each cert’s Subject Key Identifier (SKI) against the next cert’s Authority Key Identifier (AKI) in the chain, you can verify the linkage holds. Note that RFC 2818 and RFC 6125 deprecate Common Name (CN) based hostname matching — current clients only consult SAN, so a certificate without a SAN extension will fail validation regardless of what the CN says.