Encrypt Online
Theme

Certificates & Site Ops

What Is Inside a PEM File?

Understand PEM boundary lines, Base64 content, and the block types that tell you whether you are looking at a certificate, a key, or a CSR.

Encrypt Online Editorial Team3 min read
Encrypt Online guide cover on a sand background with the headline "Inside a PEM file". X.509 sits across a broad folded certificate page, with reserved space beneath the fold. A large 64 sits above a slim left-pointing arrow: return from Base64 to the original content.

A PEM file is not automatically "a certificate file." It is a text envelope. The label in the boundary lines declares the intended object type, such as a certificate, CSR, public key, or private key, but a parser must confirm that the decoded structure matches the label.

Read the first PEM boundary line before trusting the filename.

Start with the label, then confirm the structure

PEM blocks are ASCII text that look like this:

Text
-----BEGIN CERTIFICATE-----
MIIDdzCCAl+gAwIBAgIUQ0examplebase64cutforbrevity...
-----END CERTIFICATE-----

The middle of a PEM block is Base64 text that wraps binary DER data.

Common labels:

Text
-----BEGIN CERTIFICATE-----
-----BEGIN CERTIFICATE REQUEST-----
-----BEGIN PRIVATE KEY-----
-----BEGIN ENCRYPTED PRIVATE KEY-----
-----BEGIN PUBLIC KEY-----
-----BEGIN RSA PRIVATE KEY-----

That label is a better clue than .pem, .crt, .cer, or .key, but it is not proof of the object type.

Safe to inspect versus stop immediately

Rough rule:

  • CERTIFICATE is usually safe to inspect and often safe to share for debugging.
  • CERTIFICATE REQUEST is usually okay to inspect, but it still reveals what will be requested.
  • PUBLIC KEY is usually safe to inspect.
  • PRIVATE KEY, RSA PRIVATE KEY, and ENCRYPTED PRIVATE KEY are sensitive material. Keep them in an approved private workflow and share only redacted public details in tickets or chat.

An encrypted private key is still a private key. The passphrase changes the storage risk, not the classification.

One PEM file can hold several blocks

A chain file often contains multiple certificates back to back:

Text
-----BEGIN CERTIFICATE-----
leaf certificate...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
intermediate certificate...
-----END CERTIFICATE-----

That is normal. It is also why "open the file and skim every boundary line" is such a useful habit. A mixed bundle may include more than you expected. The Certificate Chain Checker inventories bounded PEM sets in source order, identifies non-certificate blocks, and excludes private material from certificate-only outputs.

PEM versus DER in plain terms

PEM and DER are usually the same underlying object in different packaging:

  • DER is binary
  • PEM is the Base64-wrapped text form with BEGIN and END lines

So when one system asks for PEM and another asks for DER, the data object is often the same certificate or key, just represented differently.

A fast inspection routine

  1. Read the BEGIN ... label.
  2. Check whether the file contains one block or many.
  3. If the label says CERTIFICATE, parse it and inspect issuer, subject, SANs, and validity dates.
  4. If the label indicates a private key, stop and handle it like secret material even before parsing.

If the value has no PEM boundary lines and you are unsure whether it is Base64, hex, a token, or another format, the String Format Identifier can provide a structural first pass. Treat that result as a format hint while keeping potentially private material in its approved workflow.

In this workflow, Key Inspector classifies one labeled key container, X.509 Certificate Parser inspects certificate fields, and CSR Decoder & Inspector reads certificate requests. When two selected blocks should belong to the same deployment, Certificate, Key & CSR Matcher compares the public key inside each object instead of comparing filenames or PEM text. PEM / DER Converter rewraps the same DER bytes when the next system wants a different encoding.

References

Report a correction