How to Read X.509 PEM Certificates & CSRs

Dealing with SSL/TLS certificates is a routine task for DevOps engineers, backend developers, and system administrators. However, opening a .pem or .crt file in a text editor only yields an incomprehensible block of Base64 text.

In this guide, we'll break down the structure of X.509 certificates and explain how to extract critical information like validity dates, issuer chains, and Subject Alternative Names (SANs).

---

What is a PEM File?

PEM (Privacy-Enhanced Mail) is the most common format for storing cryptographic keys and certificates. It consists of Base64-encoded ASN.1 (Abstract Syntax Notation One) binary data, wrapped in ASCII header and footer lines.

A standard certificate looks like this:

-----BEGIN CERTIFICATE-----
MIIDRjCCAi6gAwIBAgIUW6w3l1Fq7vjK...
...base64 payload...
-----END CERTIFICATE-----

A Certificate Signing Request (CSR), which you generate to request a certificate from a Certificate Authority (CA), looks like this:

-----BEGIN CERTIFICATE REQUEST-----
MIICvDCCAaQCAQAwdzELMAkGA1UEBh...
...base64 payload...
-----END CERTIFICATE REQUEST-----

---

Key Fields in an X.509 Certificate

When you parse the Base64 payload of an X.509 certificate, you reveal a structured data hierarchy containing several critical fields:

1. Subject (The Owner)

The Subject represents the entity the certificate was issued to.

• CN (Common Name): The primary domain name (e.g., api.example.com).
• O (Organization): The legal name of the company.
• C / ST / L: Country, State, and Locality.

2. Issuer (The Certificate Authority)

The Issuer identifies the Certificate Authority (CA) that signed and validated the certificate, establishing the Chain of Trust (e.g., Let's Encrypt, DigiCert, Cloudflare).

3. Validity Period

Every certificate has a strict expiration window defined by two timestamps:

• Not Before: The exact time the certificate becomes valid.
• Not After: The exact time the certificate expires. Browsers will throw aggressive security warnings (ERR_CERT_DATE_INVALID) if this date passes.

4. Subject Alternative Names (SANs)

In modern TLS, the Common Name (CN) is deprecated for hostname validation. Browsers now strictly rely on the SAN extension to determine which domains the certificate covers. A single certificate can secure multiple domains (e.g., example.com and *.example.com) by listing them as DNS tags in the SAN array.

5. Cryptographic Properties & Public Key

This section details the mathematical algorithms securing the certificate.

• Public Key Algorithm: Usually RSA or ECDSA (Elliptic Curve).
• Key Size: The strength of the key (e.g., 2048-bit or 4096-bit for RSA; 256-bit for ECDSA).
• Signature Algorithm: The hashing algorithm the CA used to sign the certificate (e.g., sha256WithRSAEncryption).

6. Fingerprints (Thumbprints)

A fingerprint is not actually embedded in the certificate; it is a cryptographic hash (SHA-1 or SHA-256) of the entire binary certificate file. Fingerprints are used by operating systems and servers to uniquely identify or pin specific certificates.

---

Decoding Certificates Securely

You can decode a certificate using OpenSSL in the terminal:

openssl x509 -in certificate.pem -text -noout

However, OpenSSL outputs a massive, difficult-to-read text wall. If you need a clean, scannable interface, use our X.509 Certificate Decoder. It processes the PEM file entirely in your browser using local JavaScript APIs, extracting the SANs, validity, and fingerprints into a structured JSON dashboard without ever transmitting your sensitive internal certificates to a remote server.