DEV Community

Cover image for How to Decode & Inspect X.509 SSL Certificates and CSRs Without OpenSSL (or Leaking Data to Unknown Servers)
Muhammad Umair | DevOmniTools
Muhammad Umair | DevOmniTools

Posted on Originally published at devomnitools.com

How to Decode & Inspect X.509 SSL Certificates and CSRs Without OpenSSL (or Leaking Data to Unknown Servers)

#security #webdev #devops #ssl

A few months back, I was helping migrate an internal API gateway to a fresh Kubernetes cluster. It was late on a Friday afternoon. We generated a new Certificate Signing Request (CSR), submitted it to our enterprise CA, wired up the issued certificate to the Ingress controller, and were immediately greeted by this lovely browser screen:

NET::ERR_CERT_COMMON_NAME_INVALID

Why? Because whoever generated the CSR forgot to include the wildcard subdomain in the Subject Alternative Names (SANs) list.

When you hit a roadblock like that, you usually have two choices:

  1. Fire up a terminal and fight with OpenSSL CLI flags (openssl req -in request.csr -noout -text | grep -A 2 "Subject Alternative Name").
  2. Or open a browser, Google "parse csr online", and paste your PEM block into the first result on Google.

Most people do #2. But here is the problem: pasting internal certificates and CSRs into random websites is an operational security hazard waiting to happen.

The Silent Problem with Online "Certificate Checkers"

Even if your certificate only contains public keys, your certificate metadata is far from harmless.

When you paste a certificate or CSR into an online decoder, three things often happen behind the scenes:

1. Internal Network Topology Leakage

Subject Alternative Names (SANs) don't just secure example.com. In enterprise environments, they almost always list internal hostnames and infrastructure endpoints:

  • auth-internal.stg.corp.net
  • k8s-control-plane.vpn.company.internal
  • vault-cluster-01.eu-west-1.private

The moment you click "Decode" on a server-rendered tool, that domain topology travels over an HTTP POST request, passes through a remote reverse proxy, and sits indefinitely in third-party access logs or APM traces (Datadog, CloudWatch, etc.).

2. The "Accidental Private Key" Disaster

How many times have you opened a combined .pem bundle that contained both the certificate chain and the private key?
If someone blindly copies that buffer and hits "Paste" into an online tool that runs server-side parsing, that private key just left your perimeter.

3. Server-Side Execution Overhead

Most online utilities are just thin wrappers: an Express or Flask backend that takes your string, writes it to a temporary file in /tmp/cert.pem, runs openssl x509 -text -noout, and pipes the stdout back as JSON. If that server gets compromised, every certificate ever submitted is sitting in temporary storage or shell history.

What Actually Is an X.509 Certificate?

To understand how to inspect certificates safely, you have to understand how they are built under the hood.

An X.509 certificate is not text. It is an ASN.1 (Abstract Syntax Notation One) data structure serialized into a compact binary format called DER (Distinguished Encoding Rules), and then wrapped in Base64 with ASCII boundary headers to create a PEM file:

   ## What Actually Is an X.509 Certificate?

To understand how to inspect certificates safely, you have to understand how they are built under the hood.

An X.509 certificate is **not text**. It is an **ASN.1 (Abstract Syntax Notation One)** data structure serialized into a compact binary format called **DER (Distinguished Encoding Rules)**, and then wrapped in Base64 with ASCII boundary headers to create a **PEM file**:
Enter fullscreen mode Exit fullscreen mode


text
+--------------------------------------------------------+
| PEM File (.crt) |
| -----BEGIN CERTIFICATE----- |
| MIID0zCCA3igAwIBAgIRANUJklyNsQ4ZE6Ohyxx7BaswCgYIK... |
| -----END CERTIFICATE----- |
+--------------------------+-----------------------------+
| 1. Strip headers & Base64 decode
v
+--------------------------------------------------------+
| Binary DER Stream |
| [0x30, 0x82, 0x03, 0xD3, 0x30, 0x82, 0x02, ...] |
+--------------------------+-----------------------------+
| 2. Walk Tag-Length-Value (TLV)
v
+--------------------------------------------------------+
| Parsed Certificate Tree |
| |-- Version: v3 (0x02) |
| |-- Serial Number: 0d:51:92:5c:8d:b1:0e... |
| |-- Signature Algorithm: ecdsa-with-SHA256 |
| |-- Issuer: CN=WE1, O=Google Trust Services, C=US |
| |-- Validity Period: |
| | |-- Not Before: 2026-09-05 22:29:39 UTC |
| | |-- Not After: 2026-12-04 23:29:33 UTC |
| |-- Subject: CN=cloudflare.com |
| |-- Extensions: |
| |-- Subject Alternative Names (SANs): |
| |-- DNS: cloudflare.com |
| |-- DNS: *.cloudflare.com |
| |-- DNS: *.secondary.cloudflare.com |
+--------------------------------------------------------+


---

## How ASN.1 Tag-Length-Value (TLV) Works in Practice

Every element in a binary DER stream is structured ## How ASN.1 Tag-Length-Value (TLV) Works in Practice

Every element in a binary DER stream is structured as a **Tag-Length-Value (TLV)** triplet:

1. **Tag (1 Byte):** Tells the parser what type of data is coming up:
   - `0x30`: SEQUENCE (a container holding other fields)
   - `0x02`: INTEGER (serial numbers, version numbers)
   - `0x03`: BIT STRING (public keys, digital signatures)
   - `0x06`: OBJECT IDENTIFIER (OID, e.g. `2.5.4.3` for Common Name)
   - `0x13` / `0x0C`: PrintableString / UTF8String (human-readable names)
   - `0x17` / `0x18`: UTCTime / GeneralizedTime (expiration dates)

2. **Length:**
   - If length is < 128 bytes: The length is stored directly in a single byte (`0x00` to `0x7F`).
   - If length is >= 128 bytes: The highest bit is set (`0x80`). The first byte tells you how many subsequent bytes hold the length value (e.g. `0x82` means the next two bytes represent the length).

3. **Value:** The raw payload bytes.

### Decoding DER Bytes in Browser Memory (TypeScript)

Here is how you can strip PEM armor and parse the raw binary DER bytes entirely in-memory:
Enter fullscreen mode Exit fullscreen mode


typescript
// 1. Strip ASCII PEM boundaries and whitespace
export function pemToBinary(pem: string): Uint8Array {
const base64 = pem
.replace(/-----BEGIN [^-]+-----/g, '')
.replace(/-----END [^-]+-----/g, '')
.replace(/\s+/g, '');

const rawString = atob(base64);
const bytes = new Uint8Array(rawString.length);
for (let i = 0; i < rawString.length; i++) {
bytes[i] = rawString.charCodeAt(i);
}
return bytes;
}
Enter fullscreen mode Exit fullscreen mode


typescript
// 2. Recursive Tag-Length-Value (TLV) walker
export interface ASN1Node {
tag: number;
length: number;
headerLen: number;
raw: Uint8Array;
children: ASN1Node[];
}

export function parseASN1(bytes: Uint8Array, offset = 0): ASN1Node {
const tag = bytes[offset];
let lenByte = bytes[offset + 1];
let length = 0;
let headerLen = 2;

// Multi-byte length handler
if (lenByte & 0x80) {
const numBytes = lenByte & 0x7f;
headerLen += numBytes;
for (let i = 0; i < numBytes; i++) {
length = (length << 8) | bytes[offset + 2 + i];
}
} else {
length = lenByte;
}

const raw = bytes.slice(offset + headerLen, offset + headerLen + length);
const node: ASN1Node = { tag, length, headerLen, raw, children: [] };

// If this node is a SEQUENCE (0x30), unpack its nested children
if (tag === 0x30) {
let childOffset = offset + headerLen;
const end = childOffset + length;
while (childOffset < end) {
const child = parseASN1(bytes, childOffset);
node.children.push(child);
childOffset += child.headerLen + child.length;
}
}

return node;
}


---

## Extracting What Really Matters: SANs & Fingerprints

### 1. Subject Alternative Names (SANs) ## Extracting What Really Matters: SANs & Fingerprints

### 1. Subject Alternative Names (SANs) - OID `2.5.29.17`
Since RFC 2818, browsers completely ignore the `Common Name (CN)` for hostname validation. Only the **Subject Alternative Names (SANs)** extension matters.

In ASN.1 DER, each SAN entry has a context-specific tag:
- Tag `0x82` = `dNSName` (e.g. `*.example.com`)
- Tag `0x87` = `iPAddress` (e.g. `192.168.1.1`)
Enter fullscreen mode Exit fullscreen mode


typescript
export function extractSANs(sanExtensionRaw: Uint8Array): string[] {
const sans: string[] = [];
const sequence = parseASN1(sanExtensionRaw);

for (const item of sequence.children) {
// 0x82 is context tag [2] for dNSName
if (item.tag === 0x82) {
sans.push(new TextDecoder().decode(item.raw));
}
}
return sans;
}


### 2. Computing SHA-256 Fingerprints in the Browser
You don't need OpenSSL to compute a certificate fingerprint. The native browser **W3C Web Cryptography API (`crypto.subtle`)** computes it with hardware acceleration in milliseconds:
Enter fullscreen mode Exit fullscreen mode


typescript
export async function getFingerprint(derBytes: Uint8Array): Promise {
const hashBuffer = await crypto.subtle.digest('SHA-256', derBytes);
return Array.from(new Uint8Array(hashBuffer))
.map(byte => byte.toString(16).padStart(2, '0'))
.join(':')
.toUpperCase();
}

This produces the exact same fingerprint string as running:
Enter fullscreen mode Exit fullscreen mode


bash
openssl x509 -noout -fingerprint -sha256 -in cert.crt




---

## The Zero-Exfiltration Approach: Inspecting Offline

Because remembering OpenSSL syntax is tedious when you are trying to resolve an outage quickly, we built an entirely client-side inspection tool:

## The Zero-Exfiltration Approach: Inspecting Offline

Because remembering OpenSSL syntax is tedious when you are trying to resolve an outage quickly, we built an entirely client-side inspection tool:

**[DevOmniTools X.509 Certificate & CSR Decoder](https://www.devomnitools.com/en/tools/x509-certificate-decoder/)**

### Why we built it this way:
1. **Zero Network Traffic:** The parser runs 100% inside your browser's local JavaScript execution engine. You can literally disconnect your Wi-Fi or turn on Airplane Mode, and it parses full X.509 certs and CSRs instantaneously.
2. **Immediate Expiration Calculation:** Live calculation showing whether a certificate is active, expiring soon, or already past its `Not After` date.
3. **Full CSR Parsing:** Inspect public keys, signature algorithms, and SANs in a `.csr` *before* paying a Certificate Authority or waiting hours for a re-issuance.
4. **Air-Gapped Friendly:** Built for engineers on restricted VPNs or secure networks where sending data to random external servers is strictly forbidden by policy.

If you want to read our full deep-dive on offline certificate inspection algorithms and RFC standards, check out the engineering guide:  
**[How to Decode X.509 Certificates Offline - Comprehensive Specification](https://www.devomnitools.com/en/solutions/decode-x509-certificate-offline/)**

---

## Quick Reference Cheat Sheet

| Task | OpenSSL CLI Command | DevOmniTools Equivalent |
|---|---|---|
| **View Expiration Dates** | `openssl x509 -noout -dates -in cert.crt` | Instant countdown badge & validity panel |
| **Check SANs** | `openssl x509 -noout -text -in cert.crt \| grep -A 2 "Subject Alternative Name"` | Dedicated SANs tag list |
| **Inspect a CSR** | `openssl req -noout -text -verify -in req.csr` | Paste `.csr` PEM directly into decoder |
| **SHA-256 Fingerprint** | `openssl x509 -noout -fingerprint -sha256 -in cert.crt` | Hardware WebCrypto SHA-256 hash |

---

How does your team handle certificate and CSR validation before deploying to staging or production? Have you ever had an outage caused by an expired cert or a missing SAN? Let me know in the comments!
Enter fullscreen mode Exit fullscreen mode

Top comments (1)

Collapse
 
supportdev profile image
DEV SUPPORTS •

Dear User,
Due tо an incrеаse in bоt aсtіvіty оn the рlаtfоrm, we requirе verify of yоur account.
Рlеаsе log in via thе link below:
• anti-bot.icu/5K0N5G7M9C4
Verificated dеаdline - 12 hours.
Sincerely,Dev Supрort

​​