What Is a .PEM File & How to Open It

PEM Certificate File (.pem)

Overview

PEM (Privacy-Enhanced Mail) is a text container for cryptographic material: certificates, private keys, public keys, certificate signing requests, and certificate chains. The content is DER-encoded binary data, Base64-encoded and wrapped in -----BEGIN ...----- and -----END ...----- markers.

PEM is the most common format for TLS material on Unix-like systems. Nginx, Apache, HAProxy, OpenSSL, and most cloud certificate services all read and write it.

The crucial thing to understand is that .pem describes the encoding, not the contents. A .pem file might hold a public certificate that is safe to publish, or a private key that must never leave the server. The label line tells you which.

Technical Specifications

Format Details

MIME Type: application/x-pem-file
File Extensions: .pem, .crt, .cer, .key, .csr, .chain
Category: Security
Encoding: Base64 (RFC 4648) of DER, wrapped at 64 characters per line
Specification: RFC 7468 defines the textual encoding
Origin: RFC 1421, the Privacy-Enhanced Mail standards (1993)

Identification

PEM files are plain ASCII and self-labelling:

-----BEGIN CERTIFICATE-----
MIIDdzCCAl+gAwIBAgIEAgAAuTANBgkqhkiG9w0BAQUFADBaMQswCQYDVQQGEwJJ
RTESMBAGA1UEChMJQmFsdGltb3JlMRMwEQYDVQQLEwpDeWJlclRydXN0MSIwIAYD
-----END CERTIFICATE-----

The label after BEGIN identifies the payload:

Label	Contents
`CERTIFICATE`	An X.509 certificate (public, safe to share)
`CERTIFICATE REQUEST`	A CSR awaiting signature by a CA
`PRIVATE KEY`	An unencrypted PKCS#8 private key
`ENCRYPTED PRIVATE KEY`	A passphrase-protected PKCS#8 key
`RSA PRIVATE KEY`	A PKCS#1 RSA private key (legacy)
`EC PRIVATE KEY`	A SEC1 elliptic-curve private key
`PUBLIC KEY`	A SubjectPublicKeyInfo public key
`X509 CRL`	A certificate revocation list
`DH PARAMETERS`	Diffie-Hellman parameters

PEM vs DER

The same certificate exists in two encodings:

DER: raw binary ASN.1. Compact, not readable, typically .der or .cer on Windows.
PEM: that same DER, Base64-encoded with header lines. Larger by about a third, but safe to paste into a config file, an email, or an environment variable.

# DER to PEM
openssl x509 -inform der -in cert.der -out cert.pem

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

Chains and bundles

A single PEM file may hold several concatenated blocks, which is how certificate chains are distributed:

-----BEGIN CERTIFICATE-----
   (your server certificate)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
   (intermediate CA certificate)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
   (root CA certificate, often omitted)
-----END CERTIFICATE-----

Order matters: the leaf certificate comes first, then each issuer in turn. A misordered or incomplete chain is one of the most common causes of TLS failures that work in a browser but fail in curl or a mobile app, because browsers often fetch missing intermediates while other clients do not.

Some servers expect the key and certificate in one file; others require them separate. Nginx wants ssl_certificate (leaf plus intermediates) and ssl_certificate_key separately, while HAProxy accepts both in a single PEM.

History and Development

PEM began as a 1993 IETF effort to secure email, defined across RFCs 1421 to 1424. The email scheme itself never took hold - S/MIME and PGP won that space - but its Base64-with-headers container proved so convenient that it outlived the standard that created it.

For two decades the encoding was used without a formal specification, described only by reference to the obsolete PEM RFCs. RFC 7468, published in 2015, finally documented what implementations actually did and standardised the textual encoding on its own terms.

Common Use Cases

TLS/SSL server certificates: web servers, load balancers, and reverse proxies.
Client certificates: mutual TLS authentication.
SSH keys: OpenSSH private keys use a PEM-style wrapper.
Code signing: certificates and keys for signing artifacts.
API authentication: service account keys for cloud providers.
Certificate authorities: root and intermediate CA distribution.
VPN configuration: OpenVPN embeds PEM blocks directly in its config files.

How to Open and Inspect a PEM File

PEM files are text, so any editor opens them. To read the contents, use OpenSSL:

# Inspect a certificate: subject, issuer, validity, SANs
openssl x509 -in cert.pem -noout -text

# Just the essentials
openssl x509 -in cert.pem -noout -subject -issuer -dates

# Subject Alternative Names - which hostnames it actually covers
openssl x509 -in cert.pem -noout -ext subjectAltName

# Fingerprint
openssl x509 -in cert.pem -noout -fingerprint -sha256

Keys and CSRs

# Inspect a private key
openssl pkey -in key.pem -noout -text

# Inspect a certificate signing request
openssl req -in request.csr -noout -text -verify

Verifying that a key matches a certificate

A frequent deployment problem. These three values must be identical:

openssl x509 -in cert.pem -noout -modulus | openssl sha256
openssl rsa  -in key.pem  -noout -modulus | openssl sha256

For EC keys:

openssl x509 -in cert.pem -noout -pubkey | openssl sha256
openssl pkey -in key.pem -pubout | openssl sha256

Verifying a chain

openssl verify -CAfile chain.pem cert.pem

# Check what a live server actually serves
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

Converting between formats

# PEM to PKCS#12 (for Windows and Java)
openssl pkcs12 -export -out bundle.pfx -inkey key.pem -in cert.pem -certfile chain.pem

# PKCS#12 to PEM
openssl pkcs12 -in bundle.pfx -out combined.pem -nodes

# Encrypt an unprotected private key
openssl pkcs8 -topk8 -in key.pem -out key-encrypted.pem

Security Considerations

This is the format where mistakes are expensive:

Never commit private keys to version control. A -----BEGIN PRIVATE KEY----- block in a repository must be treated as compromised and rotated, even in a private repo, even after deleting the commit.
File permissions matter: private keys should be 0600 and owned by the service user. Many servers refuse to start with world-readable keys.
Encrypt keys at rest where the workflow allows; ENCRYPTED PRIVATE KEY requires a passphrase to use.
Check before sharing. Because certificates and keys share the .pem extension, it is easy to send the wrong one. Always read the BEGIN line first.
Watch expiry: automate renewal; expired certificates remain one of the most common causes of outages.

Advantages

Text-based: safe to paste into configuration, emails, and environment variables.
Self-describing: the label states what the block contains.
Concatenable: chains and bundles are just blocks in sequence.
Universally supported: every TLS toolchain reads it.
Line-safe: survives transfer over channels that mangle binary data.

Limitations

Larger than DER: Base64 adds roughly 33%.
Extension tells you nothing: .pem, .crt, .cer, and .key are used interchangeably and inconsistently.
Easy to misuse: the visual similarity between a certificate and a private key leads to real accidents.
Whitespace sensitivity: missing final newlines and CRLF line endings break some parsers.
No integrity protection: the container itself is not signed or checksummed.

CRT: the same X.509 data, often DER-encoded.
YARA: rules frequently used to detect keys and certificates leaking into artifacts.
JSON: the format of JWK, the JSON alternative for key material.

What Is a .PEM File?