How to Read a PEM Certificate File: X.509 Parsing Guide

To read a PEM certificate file, you must decode its Base64 container to access the underlying ASN.1-structured X.509 data, which exposes essential cryptographic metadata such as subject identity, issuer details, validity dates, and public keys. You can inspect PEM files locally using command-line utilities like OpenSSL or directly within your Web browser using client-side WebCrypto APIs.

Key definitions: X.509, PEM, DER, CA, and SAN

Public key infrastructure (PKI) relies on standardized cryptographic protocols and file encodings to establish digital trust:

• X.509 Standard (RFC 5280): The international standard defining the format of public key certificates. Defined in IETF RFC 5280, X.509 specifies how identities are bound to public keys via digital signatures.
• PEM Format (Privacy-Enhanced Mail): A text container defined in RFC 7468 encapsulating binary data using Base64 ASCII headers like -----BEGIN CERTIFICATE-----.
• DER Encoding (Distinguished Encoding Rules): The binary serialization scheme defined by ITU-T X.690. PEM certificates encapsulate Base64-encoded DER binary payloads.
• Certificate Authority (CA): A trusted entity (such as Let’s Encrypt or DigiCert) that verifies domain ownership and cryptographically signs X.509 certificates.
• SAN Extension (Subject Alternative Name): An RFC 5280 extension allowing a single certificate to secure multiple domains, subdomains, or IP addresses.

Structure of a PEM certificate file

A PEM certificate file is an ASCII text container that transports binary DER data safely across text-based protocols. Understanding its structure helps debug malformed files and decode attributes.

1. Header and footer boundary markers

Every standard PEM certificate begins and ends with strict ASCII boundary markers. These markers inform cryptographic parsers of the encapsulated data type:

-----BEGIN CERTIFICATE-----
MIIEczCCA1ugAwIBAgIQAf2p655935749301...
[Base64 Encoded Payload Body]
...839210485920194857==
-----END CERTIFICATE-----

If a PEM file contains a private key or a certificate signing request (CSR), the boundary marker reflects the specific object type, such as -----BEGIN PRIVATE KEY----- or -----BEGIN CERTIFICATE REQUEST-----.

2. Base64 payload block

Between the boundary markers lies the Base64-encoded payload. Base64 encodes binary bytes into 64 printable ASCII characters (A–Z, a–z, 0–9, +, and /, with = used for padding). Lines within the Base64 block are traditionally formatted to a maximum of 64 or 76 characters per line, separated by standard newline breaks.

3. ASN.1 abstract syntax and DER structure

When the Base64 payload is decoded, it yields binary DER data structured according to ASN.1 (Abstract Syntax Notation One). ASN.1 uses Tag-Length-Value (TLV) encoding to organize certificate attributes into a hierarchical tree. The top-level ASN.1 structure of an X.509 v3 certificate consists of three main elements:

1. tbsCertificate (To Be Signed Certificate): Contains serial numbers, validity windows, issuer and subject names, public key info, and X.509v3 extensions.
2. signatureAlgorithm: Specifies the signing algorithm (e.g., sha256WithRSAEncryption).
3. signatureValue: The CA’s digital signature verifying certificate integrity.

Step-by-step: how to read and inspect a PEM certificate file

Follow these five steps to inspect and analyze any .pem or .crt file:

Step 1: Open the file and verify boundary headers

Open the certificate file and verify it begins with -----BEGIN CERTIFICATE----- and ends with -----END CERTIFICATE----- without preceding blank lines.

Step 2: Decode the Base64 payload

To inspect binary ASN.1 structures via terminal, convert Base64 to binary DER:

grep -v '^-' cert.pem | base64 --decode > cert.der

Step 3: Parse X.509 fields using OpenSSL

The standard tool for inspecting certificates on local systems is OpenSSL. Run the following command to parse and print all human-readable fields from a PEM certificate:

openssl x509 -in cert.pem -text -noout

Step 4: Inspect specific fields via targeted flags

Isolate specific attributes using dedicated OpenSSL flags:

• Check validity dates: openssl x509 -in cert.pem -dates -noout
• Check subject name: openssl x509 -in cert.pem -subject -noout
• Check issuer name: openssl x509 -in cert.pem -issuer -noout
• Check SHA-256 fingerprint: openssl x509 -in cert.pem -fingerprint -sha256 -noout

Step 5: Inspect certificates instantly in your browser

Alternatively, inspect certificates in your browser using the client-side certificate extractor. It parses X.509 files 100% locally in your browser with zero server uploads.

Certificate fields explained

Decoding an X.509 certificate exposes several standardized fields essential for identity verification:

Certificate Field	ASN.1 Element Name	Technical Purpose & Description
Subject Common Name (CN)	subject.commonName	Specifies the primary domain name (FQDN) bound to the certificate (e.g., example.com).
Issuer Name	issuer	Identifies the issuing Certificate Authority name and organisation.
Not Before / Not After	validity.notBefore / notAfter	UTC timestamps defining the valid lifetime of the certificate.
Serial Number	serialNumber	Unique positive integer assigned by the issuing CA for revocation tracking.
Certificate Fingerprint	hash/fingerprint	Cryptographic hash (SHA-256/SHA-1) over the DER payload used for verification.
Public Key Algorithm	subjectPublicKeyInfo	Defines the public key algorithm (RSA, ECDSA) and key length.

Subject Alternative Names (SANs) vs Common Name (CN)

Historically, browsers matched domain names against the Common Name (CN) field. However, this approach presented severe limitations for modern web infrastructure.

The deprecation of Common Name (CN)

Under RFC 6125 and modern browser security standards, the CN field is deprecated. Browser hostname verification relies exclusively on the Subject Alternative Name (SAN) extension.

Single vs multi-domain certificates

The SAN extension allows administrators to secure multiple domain names and pattern types under a single certificate structure:

• Single Domain Certificates: List a single domain (e.g., example.com) in the SAN extension, with an automatic alias for www.example.com.
• Wildcard Certificates: Use wildcards in the SAN entry (e.g., *.example.com) to secure an unlimited number of first-level subdomains under a primary domain.
• Multi-Domain (SAN/UCC) Certificates: Include multiple distinct domains (e.g., example.com, example.org, and api.service.net) in a single certificate’s SAN array.

When inspecting a PEM file, check the X509v3 Subject Alternative Name extension block to confirm all destination hostnames are explicitly listed.

PEM vs DER vs CRT vs PFX: certificate format comparison

Digital certificates exist in several formats across operating systems. The comparison table summarizes key technical differences:

Format	Extensions	Encoding Type	Includes Private Key?	Primary Use Case & Compatibility
PEM	.pem, .crt, .cer, .key	Base64 ASCII Text	Optional (Can store cert, chain, or key)	Apache, Nginx, Linux services, OpenSSL, Cloudflare.
DER	.der, .cer	Binary ASN.1 DER	No (Public cert only)	Java KeyStore (JKS), Windows OS, embedded devices.
CRT	.crt	Base64 ASCII or Binary	No (Public cert only)	Standard public certificate file extension on Unix systems.
PFX / PKCS#12	.pfx, .p12	Binary Password-Protected	Yes (Cert + CA Chain + Private Key)	Microsoft IIS, Windows Server, macOS Keychain export.

Converting between certificate formats

You can convert files between these formats using standard OpenSSL commands:

# Convert PEM to DER binary format
openssl x509 -in cert.pem -outform der -out cert.der

# Convert DER binary to PEM text format
openssl x509 -inform der -in cert.der -outform pem -out cert.pem

# Bundle PEM certificate and private key into PKCS#12 (.pfx)
openssl pkcs12 -export -out cert.pfx -inkey private.key -in cert.crt -certfile chain.crt

Checking SSL/TLS certificate expiration dates

Public SSL/TLS certificates have a maximum validity period of 398 days. Monitoring expiration dates prevents site outages and security warnings.

Command-line expiration check

To print the exact expiration date of a local PEM file, run:

openssl x509 -in cert.pem -enddate -noout

The output returns the timestamp in GMT format:

notAfter=Sep 22 23:59:59 2026 GMT

Calculating remaining validity days

To check whether a certificate will expire within a specific timeframe (e.g., 30 days / 2,592,000 seconds), use OpenSSL’s -checkend flag:

openssl x509 -in cert.pem -checkend 2592000 -noout

If the command returns Certificate will not expire, the certificate has more than 30 days of validity remaining. If it returns Certificate will expire, immediate renewal is required.

Common certificate errors and troubleshooting

Administrators frequently encounter three primary certificate error types during deployment:

1. Expired Certificate (ERR_CERT_DATE_INVALID)

Occurs when the system clock falls outside the certificate’s notBefore or notAfter validity window. Web browsers block access to sites with expired certificates to protect users from intercepted sessions. Resolve this error by reissuing the certificate through your CA.

2. Invalid PEM Header or Malformed Base64

Parsers throw errors like unable to load certificate or PEM_read_bio: no start line when line breaks or boundary markers are damaged. Ensure that:

• The header has exactly five hyphens: -----BEGIN CERTIFICATE-----.
• No carriage returns (\r) or hidden control characters break the header.
• No trailing space characters exist after the Base64 lines.

3. Broken Chain of Trust (UNTRUSTED_ISSUER)

Occurs when a web server serves the leaf certificate without including the intermediate CA certificates. Browsers cannot verify the trust path back to a trusted Root CA without the intermediate chain. Fix this issue by concatenating your leaf certificate and intermediate certificates into a single PEM bundle:

cat your_domain.crt intermediate.crt root.crt > fullchain.pem

Security and privacy: why local browser parsing is critical

Certificate files are often managed alongside private keys (.key) or PKCS#12 bundles (.pfx). Uploading certificates to server-based online converters introduces severe security risks:

• Private Key Exposure: If a private key file is accidentally uploaded alongside a certificate to a third-party server, attackers who intercept or log the upload can compromise server decryption and impersonate your domain.
• Internal Network Footprinting: Internal TLS certificates for non-public hostnames (e.g., vault.internal.company.local) reveal private IP structures, internal domain schemes, and infrastructure details to external logging systems.
• Compliance & Regulatory Violations: Sending infrastructure credentials to unauthorized cloud services violates strict data privacy standards, including GDPR, HIPAA, and SOC 2 guidelines.

By conducting certificate inspection locally using client-side JavaScript WebCrypto decoders like the certificate extractor, your file data remains completely sandboxed within your local browser memory. Zero bytes leave your device, ensuring total privacy for sensitive certificates.

Frequently asked questions

1. What is the difference between a .pem file and a .crt file?

A .pem file is a container format that uses Base64 ASCII text encoding to store certificates or private keys. A .crt file is a file extension typically used to designate a public certificate. In Unix environments, .crt files are frequently PEM-encoded, meaning a .pem file and a .crt file often contain identical data structures.

2. Can a PEM file contain both a public certificate and a private key?

Yes. Because PEM files rely on distinct boundary markers, a single .pem file can store multiple cryptographic objects concatenated sequentially. For example, a single PEM file may include -----BEGIN CERTIFICATE----- blocks for the leaf and intermediate certificates, followed by a -----BEGIN PRIVATE KEY----- block.

3. How can I extract a public key from a PEM certificate using OpenSSL?

You can extract the public key portion from an existing X.509 PEM certificate by executing the following OpenSSL command: openssl x509 -in cert.pem -pubkey -noout > public.key. This isolates the public key algorithm and key parameter block into a standalone PEM file.

4. Why does my browser mark a certificate as untrusted if the PEM file is valid?

A PEM certificate may be syntactically valid yet untrusted by browsers if the issuing Certificate Authority is not present in the operating system’s root trust store, if the certificate has expired, or if the server failed to transmit the required intermediate CA bundle required to complete the trust chain.

5. How do I convert a PEM certificate to DER binary format?

To convert a PEM certificate into binary DER encoding, use OpenSSL: openssl x509 -in cert.pem -outform der -out cert.der. This strips the ASCII header, footer, and Base64 wrapping, leaving only the raw binary ASN.1 DER data.

6. What happens when an SSL certificate expires?

When an SSL certificate expires, web browsers display critical security warnings (such as Your connection is not private) and block users from accessing the site. Automated API clients and HTTPS web services immediately fail TLS handshakes, causing service disruption until a valid, renewed certificate is installed.

7. Is it safe to upload a PEM file to an online certificate inspector?

It is only safe if the online tool executes 100% client-side parsing within your web browser. Conventional online tools that process uploads on backend servers create security risks. Using a client-side parser guarantees that your certificate and any associated keys remain private on your machine.

Related tools and reading

Explore related browser tools and technical guides for inspecting and managing file metadata across different formats:

• Certificate Extractor — Parse X.509 SSL/TLS certificates and inspect SANs, validity, and issuer details 100% privately in your browser.
• Office Metadata Extractor — Inspect and remove author names, revision logs, and hidden properties from Word, Excel, and PowerPoint files.
• PDF Metadata Extractor — View document properties, embedded attachments, creation dates, and digital signature structures inside PDF files.

Sources and references

This technical guide cites specifications published by the IETF and ITU-T:

• IETF RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. Available at: https://datatracker.ietf.org/doc/html/rfc5280
• IETF RFC 7468: Textual Encodings of PKIX, PKCS, and CMS Structures (PEM Encodings). Available at: https://datatracker.ietf.org/doc/html/rfc7468
• ITU-T Recommendation X.509: Information Technology – Open Systems Interconnection – The Directory: Public-key and attribute certificate frameworks. Available at: https://www.itu.int/rec/T-REC-X.509
• IETF RFC 6125: Representation and Verification of Domain-Based Application Service Identity in PKI. Available at: https://datatracker.ietf.org/doc/html/rfc6125