Bridge SSL
Bridge CDN →

What is a PEM file? Format, labels and line rules

8 min readUpdated

A PEM file is a text file that holds a certificate, a key or a signing request as base64 between a -----BEGIN line and an -----END line. RFC 7468 defines this textual encoding and traces it, name included, back to Privacy-Enhanced Mail, the email standard of RFC 1421 [1]. This SSL and TLS glossary entry covers what a PEM block contains, what its label means and when a parser accepts the text.

Block
a -----BEGIN label----- line, base64 lines, an -----END label----- line with the same label [1]
Inside
one binary ASN.1 structure per block, DER preferred: a certificate, key, request or revocation list [1]
Line length
64 characters per line when written, the last line up to 64 [1]
Size
every 3 bytes of binary become 4 base64 characters (RFC 4648 §4) [2]
File names
.crt and, from many tools, .cer [1], as well as .pem; the extension is a convention, not the format

What one PEM block contains

A PEM block has three parts. RFC 7468 calls the first and the last encapsulation boundaries and is exact about both [1].

  1. The opening line, or pre-encapsulation boundary: exactly five hyphens, BEGIN, one space, the label, five more hyphens.

  2. The body: the binary structure in base64, using the letters A to Z and a to z, the digits, + and /, with = as padding [2].

  3. The closing line: the same pattern with END and the same label.

-----BEGIN CERTIFICATE-----
MIICcjCCAhigAwIBAgIUIjtcM7f5O3z6sHIpiCpBPfDNuJEwCgYIKoZIzj0EAwIw
JDEiMCAGA1UEAwwZRXhhbXBsZSBUZXN0IEludGVybWVkaWF0ZTAeFw0yNjEwMTUx
...
-----END CERTIFICATE-----

The text adds nothing to the certificate. Decode the body and you get the certificate's DER bytes; the 630-byte test certificate behind this example becomes 840 base64 characters. The old mail format allowed header lines inside the block. RFC 7468 does not: between the boundaries there is only base64 [1].

PEM labels and what they mean

The label names the structure, so a PEM-format file tells you what it holds before you decode anything [1].

LabelWhat the block holdsRFC 7468
CERTIFICATEan X.509 certificate§5
CERTIFICATE REQUESTa PKCS #10 certification request (CSR)§7
X509 CRLa certificate revocation list§6
PRIVATE KEYan unencrypted PKCS #8 private key§10
ENCRYPTED PRIVATE KEYa password-encrypted PKCS #8 private key§11
PUBLIC KEYa public key with its algorithm (SubjectPublicKeyInfo)§13
PKCS7, CMSsigned or enveloped messages, including bundles of certificates§8, §9

Older labels still turn up in a PEM file. X509 CERTIFICATE is one that conforming software must no longer write, and NEW CERTIFICATE REQUEST is one that parsers may treat as CERTIFICATE REQUEST [1]. RSA PRIVATE KEY and EC PRIVATE KEY are not in RFC 7468 at all: they are OpenSSL's older "traditional" key format, covered under private keys below [3][5].

One file, several blocks

A PEM file may contain more than one block, and RFC 7468 leaves the order to the context of use [1]. That is how a server certificate and its intermediate travel together as a certificate chain in one fullchain.pem. The order such a file needs is covered on the certificate formats page of the certificates section.

Counting blocks is a text search. Reading them is where commands differ. In this test on OpenSSL 3.0.13, with a chain made for this page, openssl x509 decoded only the first certificate and openssl storeutl listed both:

$ grep -c 'BEGIN CERTIFICATE' fullchain.pem
2
$ openssl x509 -in fullchain.pem -noout -subject
subject=CN = example.com
$ openssl storeutl -noout -certs fullchain.pem
0: Certificate
1: Certificate
Total found: 2

A certificate and its key can also share a file. OpenSSL's PEM readers skip blocks of a type they are not looking for [3]. A client authentication certificate for mutual TLS is passed to openssl s_client as files: the certificate with -cert, its key with -key, extra chain certificates with -cert_chain [6].

Line rules, and what a parser accepts

Software that writes PEM must break the base64 into lines of exactly 64 characters and add no stray whitespace; software that reads it may accept other line lengths, must cope with different newline conventions and must not fail on text placed before the opening line [1]. RFC 7468 also records that extant parsers "diverge considerably" on whitespace. A file that one program reads can be refused by another.

What OpenSSL 3.0.13 did with altered copies of the same PEM certificate:

Change to the fileResult
base64 rewrapped to 128-character linesread; same fingerprint
a Subject: line of text before -----BEGINread; same fingerprint
Windows line endings (CRLF)read; same fingerprint
END line with a different labelrefused: Could not read certificate
four hyphens instead of five on the END linerefused: Could not read certificate

So when a pasted certificate is rejected, look at the two boundary lines first: in this test, one missing hyphen was enough for OpenSSL to refuse the file.

The same certificate in different text

PEM text is not canonical. Two files can differ in line length, line endings and explanatory text and still hold the same certificate; RFC 7468 says canonical comparison means decoding to DER, and that hashes for identification are computed over DER [1]. openssl x509 -fingerprint does exactly that: it digests the DER encoding of the whole certificate [4].

$ openssl x509 -in cert.pem -noout -fingerprint -sha256
sha256 Fingerprint=9A:D5:D2:6D:C1:E3:6C:6C:...
$ openssl x509 -in cert.pem -outform der -out cert.der
$ openssl dgst -sha256 cert.der
SHA2-256(cert.der)= 9ad5d26dc1e36c6c...

The rewrapped copy from the table above gives the same value. Compare two PEM certificates by fingerprint, never with diff. Pins work on decoded data too. An app pinning a certificate compares a hash of the certificate or of its public key, computed over the decoded structure, so rewrapping or re-saving the PEM file does not break the pin.

Private keys in PEM

OpenSSL reads private keys in PKCS #8 and in its older traditional format, encrypted or not [3]. In a PEM file that shows up as labels such as these:

  • PRIVATE KEY is PKCS #8, the standard form under RFC 7468 §10. openssl pkey writes it by default [5].

  • ENCRYPTED PRIVATE KEY is PKCS #8 protected by a password [1].

  • RSA PRIVATE KEY and EC PRIVATE KEY are traditional forms of RSA and EC keys, written with -traditional. OpenSSL's documentation reserves the traditional format for "compatibility with legacy programs" [3][5].

An encrypted traditional key still carries header lines inside the block, which RFC 7468 does not allow [1]:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC,...

OpenSSL describes this encryption as a non-standard technique [3]. Converting is one command, openssl pkey -in old.key -out new.key, which writes PRIVATE KEY [5]. On an encrypted key that output is unencrypted; add a cipher such as -aes-256-cbc to get ENCRYPTED PRIVATE KEY instead [5]. Base64 is an encoding, not protection: anyone who can read an unencrypted PRIVATE KEY block in a PEM file has the key.

Where PEM fits among formats

PEM and DER carry the same structure, one as base64 text and one as binary. Bundles such as PKCS #12 are separate containers, and converting between all of them is on the certificate formats page; reading a certificate's fields is on the OpenSSL commands page and the X.509 entry.

Extensions do not settle the question. RFC 7468 asks for .crt on PEM certificates and notes that many tools write PEM with .cer [1], although the RFC 2585 registration says a .cer file holds exactly one DER certificate [7]. Open the file: text with a -----BEGIN line is PEM.

Bridge SSL is the certificate layer of Bridge CDN. TLS is terminated at the edge, so there is no certificate file on your machine and no chain to assemble, and Bridge SSL has no certificate upload.

FAQ

What does PEM stand for?

Privacy-Enhanced Mail. RFC 7468 traces the text format back to that email standard, RFC 1421, and now defines it for certificates, keys and requests.

Is a .crt file the same as a .pem file?

It can be. A .crt file can hold a PEM certificate or a binary DER one. The name proves nothing; a -----BEGIN line in the text does.

Can one PEM file hold a certificate and its private key?

Yes. A PEM file can carry blocks of different types one after another, and OpenSSL picks the block type it needs. Protect such a file as you would protect the key alone. [3]

How do I see what a PEM file contains?

List the labels with grep -- '-----BEGIN' file.pem. To decode every certificate in the file, run openssl storeutl -noout -text -certs file.pem. [6]

Sources

  1. RFC 7468, Textual Encodings of PKIX, PKCS, and CMS Structures: §1, §2, §4, §5.1–§5.3, §6–§11, §13, §14, Appendix B.

  2. RFC 4648, The Base16, Base32, and Base64 Data Encodings, §4.

  3. OpenSSL 3.0 manual: PEM_read_bio_PrivateKey, Description, Notes, PEM encryption format.

  4. OpenSSL 3.0 manual: openssl-x509, option -fingerprint.

  5. OpenSSL 3.0 manual: openssl-pkey, option -traditional.

  6. OpenSSL 3.0 manual: openssl-s_client (-cert, -key, -cert_chain) and openssl-storeutl (-certs, -text).

  7. RFC 2585, Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP.