Certificate formats: PEM, DER, PFX and when to convert

Certificate formats such as PEM, DER and PFX are different ways of storing the same certificate on disk. The certificate itself is a fixed structure, identical whatever file it arrives in; what varies is how it is encoded and what else is bundled with it, and those two variations account for every format name you will meet.

Understanding them as encoding plus contents, rather than as unrelated file types, makes conversion obvious instead of arbitrary.

Two questions, not a list

• How is it encoded? Either as raw binary, or as that same binary encoded into text with header and footer lines around it. The text form exists so that certificates can be pasted into configuration files, emails and control panels.

• What is in the file? Just a certificate, a certificate with its chain, a certificate with its private key, or a request or key alone.

Every format is a combination of those answers. The confusion comes from tools naming the combination rather than the parts.

The formats you will meet

PEM is the common currency. It is text, it is what most Unix-derived software expects, and several items can sit in one file one after another, which is how a certificate and its chain are usually supplied. Its text encoding is described in RFC 7468.

DER is the same content without the text wrapper; some platforms and devices expect it. PKCS#12 bundles everything needed to serve a site, including the private key, into one password-protected file, which is what platforms with a single import field usually want. PKCS#7 carries certificates without any key, so it is used for delivering a chain.

File extensions are not reliable. A file ending in .cer or .crt may hold either PEM or DER, because extensions are conventions and tools disagree about them.

Telling them apart

Open the file in a text editor. That single step answers most questions.

Readable lines beginning with dashes mean the text form, and the label says what follows: -----BEGIN CERTIFICATE----- for a certificate, -----BEGIN PRIVATE KEY----- for a key, -----BEGIN CERTIFICATE REQUEST----- for a signing request. Binary noise means one of the binary forms.

Counting the labelled blocks tells you how many items are in the file, which is how you check whether a chain is included without decoding anything. To read what a certificate says, decode it:

$ openssl x509 -in cert.pem -noout -text
$ openssl x509 -in cert.der -inform der -noout -text

What conversion actually does

Conversion re-encodes, and nothing else. The certificate inside is unchanged: the same names, the same dates, the same signature. Converting cannot fix an expired certificate, cannot add a name, and cannot repair a mismatched key.

That matters because conversion is often attempted as a remedy. If a certificate is rejected for its contents, no format change will help; if it is rejected because the software cannot read the file, conversion is exactly the answer.

The one thing conversion can change is what is bundled: extracting a certificate from a combined file, or assembling a certificate and key into one, alters the contents even though each item stays the same.

Converting with OpenSSL

The common conversions are one command each:

$ openssl x509 -in cert.pem -outform der -out cert.der
$ openssl x509 -in cert.der -inform der -out cert.pem
$ openssl pkcs12 -in bundle.pfx -out bundle.pem -noenc
$ openssl pkcs12 -export -in cert.pem -inkey key.pem -certfile chain.pem -out bundle.pfx
$ openssl pkcs7 -print_certs -in chain.p7b -out chain.pem

In order: PEM to DER, DER to PEM, PFX to PEM, PEM to PFX with the chain, and P7B to PEM. Two of them deserve a warning. Extracting a PFX with -noenc writes the private key to disk unencrypted, so the output needs the same protection as the key itself. And a .cer file has to be checked first: if it is already PEM, there is nothing to convert.

Mistakes that produce broken installations

Four mistakes account for most format-related incidents.

• Assembling a bundle in the wrong order. Where a file holds a certificate and its chain, your certificate goes first, then each intermediate towards the root. Software that reads such a file positionally presents the wrong certificate if the order is reversed, which produces a trust error described on ERR_CERT_AUTHORITY_INVALID.

• Including the root. Unnecessary in every case, as covered on certificate chains. Some software objects to it, so leaving it out avoids a class of confusion.

• Pasting with damage. Copying text through an editor that reflows lines, or through a chat client, can break the encoding invisibly. If a file that looks correct is rejected as unreadable, this is the likely cause, and the answer is to transfer it as a file rather than as text.

• Converting a bundle and losing the chain. Extracting a single certificate from a combined file drops the intermediates. The result works in a browser that has them cached and fails elsewhere.

Why so many formats exist

The binary encoding came first, as part of a general standard for structured data that predates the web. The text form was added because binary files are awkward in the places certificates actually travel: configuration files, emails, support tickets and web forms. Text survives being pasted; binary does not.

The bundle formats solve a different problem. A working installation needs a certificate, its chain and a private key, and moving three files in step is error-prone. A single password-protected container solves that, at the cost of being opaque without tooling.

Nothing about a format is a quality judgement. A file is not better for being one form or another; it is readable by the software you are handing it to, or not.

Which format do you need

The software that reads the file decides. Most Unix-derived server software expects PEM, with the certificate and chain in one file and the key in another. Platforms offering a single import field usually expect PKCS#12. Devices and appliances vary, and their documentation is the authority.

Where a certification authority or provider gives you several files without explaining them, opening each in a text editor and reading the labels tells you what you have in under a minute.

FAQ