SSL certificate formats explained: PEM, DER, P7B, PFX and JKS

Every certificate mess starts the same way: a certificate authority hands you files in one format, and the thing you are configuring demands another. The certificate inside never changes — the same public key, the same signature, the same validity dates — but the packaging differs, and servers are fussy about packaging. This guide explains each format you will meet, how to identify a mystery file in seconds, and the shortest path between any two of them.

First, what is actually in these files?

Three kinds of material travel together in the TLS world: the certificate itself (public, sent to every visitor), the intermediate chain that links your certificate to a trusted root, and the private key (secret, never to be shared). Formats differ mainly in which of these they can carry and how they are encoded. That is the whole subject in one sentence: everything below is detail.

PEM — the universal text format

Open a PEM file in any text editor and you will recognise it instantly: -----BEGIN CERTIFICATE----- followed by a wall of Base64. PEM is just a binary structure wrapped in text armor, which makes it copy-pasteable into terminals, config files and web forms — the reason it became the lingua franca. Extensions vary wildly (.pem, .crt, .cer, .key) but the BEGIN line tells you what is inside: a certificate, a private key, a certificate request, and so on. Nginx, Apache, HAProxy, and virtually every load balancer and programming language accept PEM. A fullchain.pem is simply several certificates concatenated in one file, leaf first.

Tools: decode and check any certificate, build a correctly ordered fullchain.pem.

DER — the same thing, in binary

DER is the raw binary encoding that PEM wraps. Strip the BEGIN/END lines, decode the Base64, and you have DER. Java tooling and some appliances ask for .der or binary .cer files. Because it is binary, opening it in a text editor shows gibberish beginning with byte 0x30 — that is how you recognise it. Converting is a pure re-encoding with zero risk: PEM → DER or DER → PEM.

P7B / PKCS#7 — a bag of certificates, never a key

A .p7b (or .p7c) file is a container that holds one or more certificates — typically your certificate plus its intermediates — and, by design, never a private key. Windows CAs and some enterprise portals love handing these out. Windows/IIS and Java tooling consume them directly; everything else wants the certificates unpacked to PEM first. Tools: P7B → PEM, PEM → P7B, and P7B + your key → PFX.

PFX / P12 — the whole identity in one encrypted file

PKCS#12 (.pfx or .p12 — same thing, two extensions) is the only mainstream format that carries the certificate, the chain and the private key together, protected by a password. That makes it the import/export format of the Microsoft world: IIS, Windows certificate stores, Azure, and also Java keystores since Java 9. It is also why PFX files deserve care — whoever has the file and its password has your identity.

Tools: bundle PEM + key into a PFX, unpack a PFX to PEM, and change or remove a PFX password — all in the browser, so the key never travels.

JKS — Java’s own keystore

The Java KeyStore (.jks, sometimes .keystore) predates PKCS#12 support in Java and is proprietary to the JVM: nothing outside the Java ecosystem reads it natively. Two useful facts: first, since Java 9 keytool actually creates PKCS#12 files by default even when they are named .jks; second, escaping a real JKS normally requires installing a JDK just to run keytool. Our JKS → PFX / PEM converter reads both variants directly in the browser, no Java required.

Identifying a mystery file in ten seconds

Text starting with -----BEGIN? PEM — the BEGIN line names the content. Binary? If the extension is .p7b it is PKCS#7; if .pfx/.p12 it is PKCS#12; if .jks try the JKS converter (it will tell you if it is secretly PKCS#12). Still unsure? Drop it on the certificate checker — it ingests PEM, DER, P7B and PFX, and reports what it found, who issued it, and when it expires.

Which format does my server want?

Nginx / Apache / HAProxy

PEM: a certificate-plus-chain file and a separate key file (HAProxy wants them concatenated into one). If the CA gave you PFX, unpack it first.

Windows / IIS / Azure

PFX. If you hold loose PEM files, bundle them; if you hold a P7B plus a key, combine those.

Java applications

Modern Java accepts PKCS#12 directly — make a PFX and point the keystore config at it. Only legacy setups still insist on true JKS.

Three rules that prevent most disasters

1. Order matters in chains.Servers must send the leaf certificate first, then intermediates. A wrong order “works on my machine” (desktop browsers cache intermediates) and fails on phones — the chain builder sorts and cryptographically verifies the links for you. 2. The key must match. After any renewal, confirm certificate and key belong together with the matcher before restarting the server. 3. Never paste a private key into a website that uploads it. Every tool linked in this guide runs entirely in your browser — that is the point of this site — but the rule applies everywhere else too.