Privacy-Enhanced Mail (PEM) is a plain-text encoding format for cryptographic objects – X.509 certificates, private keys, certificate signing requests, and certificate chains – that wraps Base64-encoded data between -----BEGIN X----- and -----END X----- delimiter lines. Despite its 1990s email-security origins, PEM is now the near-universal container format for TLS certificates and keys.
Key takeaways
- PEM wraps Base64-encoded certificate or key data between BEGIN/END lines.
- Named for a 1990s email-encryption standard, now used almost only for certs.
- The plain-text format makes PEM files easy to copy, paste, and version.
- Versa Director and VMS require CA certificates and keys in PEM format.
- PEM encodes the same X.509 data that binary DER format stores as bytes.
On this page: Why it mattersHow it worksTypesPEM & VersaFAQ
Why is PEM important?
Certificates and keys are binary data, but the systems that move them – email attachments (PEM’s original use case), config files, copy-paste into a console – are not always safe for binary content. PEM re-encodes that structure as Base64 text bounded by readable delimiter lines, so a certificate or key survives transport through text-only channels intact.
That portability made PEM the default exchange format across the TLS and PKI ecosystem, even though its original purpose – email encryption under the 1993 IETF standard – never caught on. OpenSSL, web servers, browsers, and network appliances all read and write PEM by default. It is the format expected when uploading a CA certificate to a firewall or configuring mutual TLS between devices, including Versa Director, VMS, and VOS nodes.
What is PEM?
A PEM file is plain ASCII text: a header line, a Base64-encoded body wrapped at 64 characters per line, and a matching footer – for example -----BEGIN CERTIFICATE----- … -----END CERTIFICATE-----. The Base64 block is the object’s DER binary encoding, defined by the ASN.1 schema for whatever it represents: a certificate, a key, a signing request, or a revocation list.
The name comes from Privacy Enhanced Mail, an IETF standard published as RFC 1421 through RFC 1424 in 1993 for encrypting and signing internet email. That standard was superseded by S/MIME and PGP, but its text encoding outlived it: RFC 7468 later formalized the same Base64-with-delimiters scheme as the standard encoding for X.509, PKCS, and CMS structures – what “PEM” now refers to.
Types of PEM files
A .pem extension can hold several object types, distinguished by the delimiter text, not the file name.
Certificates use -----BEGIN CERTIFICATE-----; a file can hold one certificate or a chain of leaf, intermediate, and root certificates. Private keys use -----BEGIN RSA PRIVATE KEY----- (PKCS#1) or -----BEGIN PRIVATE KEY----- (PKCS#8), and can be encrypted. CSRs use -----BEGIN CERTIFICATE REQUEST----- and carry the identity and public key sent to a CA for signing. CRLs use -----BEGIN X509 CRL----- and list certificates a CA has revoked.
PEM should not be confused with PKCS#12 (.pfx/.p12), a binary, password-protected bundle – PEM stays plain text and keeps certificates and keys separate.
PEM & Versa
Versa systems require certificates and keys in PEM format at several points. Install and Configure VMS generates a full certificate set – root CA, intermediate CA, server, and client – as .pem files; root-ca-cert.pem is uploaded to a Director node’s Files and Folders directory so VOS devices trust the Versa Messaging Service (VMS), while server-cert.pem is uploaded to Director when configuring the VMS connector for TLS, which requires PEM format. The HA-based VMS deployment guide covers generating and validating that same chain for a highly available VMS cluster.
PEM also appears during maintenance: upgrading Versa nodes to Ubuntu 18.04 requires any replacement UI certificate in PEM format, and public-cloud nodes are reached over SSH using a PEM key file.
Frequently asked questions
What does PEM stand for?
PEM stands for Privacy-Enhanced Mail, a 1993 IETF standard (RFC 1421–1424) for encrypting and signing internet email. The standard was not widely adopted, but its Base64-with-delimiters encoding was reused for certificates and keys, and is what “PEM” now commonly refers to.
How is a PEM file different from a DER file?
Both encode the same underlying data – typically a certificate or key – but DER is raw binary, while PEM is that same data Base64-encoded and wrapped between -----BEGIN-----/-----END----- lines. PEM is text-safe; DER is more compact but cannot be opened as text.
Can one PEM file contain more than one certificate?
Yes. A PEM file can concatenate multiple -----BEGIN CERTIFICATE-----/-----END CERTIFICATE----- blocks in sequence to form a full certificate chain – commonly the server’s leaf certificate, followed by one or more intermediate certificates, and sometimes the root CA certificate as well.
Is a PEM private key always encrypted?
No. A PEM private key can be stored unencrypted, readable by anyone who opens the file, or encrypted with a password using headers such as Proc-Type: 4,ENCRYPTED or the -----BEGIN ENCRYPTED PRIVATE KEY----- format. Unencrypted keys should have restrictive file permissions.
What file extensions are used for PEM-encoded files?
.pem is most common, but .crt, .cer (certificates), .key (private keys), and .csr (signing requests) are frequently PEM-encoded too. The extension is only a naming convention – opening the file and checking for -----BEGIN-----/-----END----- delimiters is the reliable way to confirm the encoding.
More on PEM
If you want to learn more, these are sources we trust.
| RFC 7468: Textual Encodings of PKIX, PKCS, and CMS Structures | RFC 1421: Privacy Enhancement for Internet Electronic Mail |
|---|---|
| The current IETF standard defining the BEGIN/END, Base64 encoding used for certificates, keys, and other PKIX and PKCS structures. | The 1993 standard that introduced the BEGIN/END Base64 encoding, as part of an email-encryption scheme later abandoned in practice. |
Related terms
If you’re reading about PEM, these are worth looking at next.
| Subject Alternative Name | SD-WAN | Wide Area Network |
|---|---|---|
| A certificate extension listing host names or IP addresses a certificate is valid for – the field TLS clients check instead of the Common Name. | A networking approach that builds encrypted overlays across WAN links – overlays that PEM-encoded certificates and keys help secure. | The broadband, MPLS, or wireless links a VOS device uses to reach the internet or remote sites, often secured with PEM certificates. |