SSL Certificate Format Converter

The extension on a certificate file is not proof of what's inside it — this trips people up constantly. .pem files are always Base64 text. .crt and .cer files are ambiguous: they can hold either PEM-encoded text or raw binary DER, and the extension alone won't tell you which. .pfx/.p12 and .p7b/.p7c files are always binary containers, never plain text.

The fastest way to check: open the file in a plain text editor. If you see readable lines starting with -----BEGIN CERTIFICATE----- (a private key uses that same wrapper with PRIVATE KEY or RSA PRIVATE KEY written where CERTIFICATE is), it's PEM — a Base64-encoded text format that can hold one certificate or several concatenated one after another. If it opens as unreadable binary bytes, it's DER, PFX, or P7B, and you need to know which container it is before picking a converter: DER holds exactly one certificate and nothing else, PFX/P12 is a password-protected container that can bundle a certificate, its private key, and a chain together, and P7B (PKCS#7) bundles one or more certificates — never a private key — which is why converting a P7B into a PFX still asks you to supply the key separately.

Once you know what you have and what you need, pick the exact direction from the 10 dedicated converters below — each is built for a single pair of formats, so it only asks for the inputs that pair actually needs. The quick converter further down this page handles PEM ⇄ DER only.

Different server software and platforms expect different certificate formats, and installing the wrong one is one of the most common SSL setup mistakes.

• Apache and Nginx read PEM — Base64 text, usually a .pem, .crt, or .key file referenced directly in the server config.
• IIS and other Windows-native services expect PFX/P12 — the single password-protected file that bundles the certificate and its private key together, which is what IIS's import wizard asks for.
• Java keystores and some Windows certificate-import tooling work with P7B — a certificate chain bundle with no private key inside, typically used to import a CA's intermediate chain rather than to carry a server's own key.
• .crt/.cer files show up in both worlds, because the extension doesn't commit to an encoding — check the content (see the block above) before assuming which one you have.

If your server documentation names the format it wants, match it to one of the five above and use the corresponding converter below rather than guessing.

All five names describe the same underlying X.509 certificate data, encoded or packaged differently:

• PEM — Base64 text wrapped in -----BEGIN-----/-----END----- lines. Can hold a single certificate, several certificates concatenated as a chain, or (in a different block type) a private key. Easy to paste, email, and diff.
• DER — the raw binary ASN.1 encoding underneath PEM. A DER file holds exactly one certificate; there's no bundling concept the way PEM text has.
• CRT / CER — not a distinct encoding, just a filename convention. A .crt/.cer file can contain either PEM text or DER bytes — you have to open it to know.
• PFX / P12 (PKCS#12) — a binary, password-protected container that can bundle a certificate, its private key, and a chain together in one file. This is the only one of the five that can carry a private key inside the container itself.
• P7B (PKCS#7) — a binary container for one or more certificates, typically a certificate plus its issuing chain, but never a private key.

Two accuracy notes worth knowing before you convert: building a new PFX (packaging a certificate and key into one) only supports RSA keys today; reading an existing PFX works with a certificate of any algorithm, RSA or ECDSA, and pulls it back out safely. Directions that don't touch PFX at all — PEM⇄DER, PEM⇄CRT, P7B→PEM — never open or inspect the certificate's key algorithm in the first place, so they aren't RSA/ECDSA-limited either way.

Every conversion runs entirely in your browser — your certificate and private key never leave it. Converting into or out of a PFX uses the node-forge library rather than the browser's native Web Crypto API, because Web Crypto has no built-in way to build or read a PKCS#12 (PFX) container. When you build a new PFX, BKNS's tool requires a password of at least 8 characters to protect the private key inside it; opening an existing PFX to read it lets you leave the password field blank, since a small number of PFX files genuinely have none.