Certificates and keys can be encoded in several different file formats, and different platforms expect different ones — converting between them is a routine task, and OpenSSL handles every common conversion with a specific, memorable command.
PEM to DER
openssl x509 -in cert.pem -outform der -out cert.derDER to PEM
openssl x509 -in cert.der -inform der -outform pem -out cert.pemPEM certificate + key to PFX/P12
openssl pkcs12 -export -out cert.pfx \
-inkey key.pem -in cert.pem -certfile ca-bundle.pemPFX/P12 back to PEM (certificate and key separately)
openssl pkcs12 -in cert.pfx -clcerts -nokeys -out cert.pem
openssl pkcs12 -in cert.pfx -nocerts -nodes -out key.pemPFX/P12 to a Java Keystore (JKS)
keytool -importkeystore -srckeystore cert.pfx -srcstoretype PKCS12 \
-destkeystore keystore.jks -deststoretype JKSWhy so many formats exist at all
PEM's plain-text, base64-encoded format traces back to early Unix cryptography tooling and remains the most common because it's easy to view, copy, and paste into config files and forms. DER is a more compact binary encoding, common in Windows and some Java contexts that predate widespread PEM adoption in those ecosystems. PFX/P12 exists specifically to bundle a certificate and its private key together in one password-protected file, useful for Windows-oriented platforms like IIS that expect a single importable file rather than separate certificate and key files. JKS is specific to the Java ecosystem's own keystore system, predating PKCS12 becoming a more universal cross-platform standard — modern Java actually supports PKCS12 directly now, reducing (though not eliminating) the need for JKS specifically in newer deployments.
A quick way to identify what format you're looking at
A PEM file is plain text, opens in any text editor, and starts with a line like -----BEGIN CERTIFICATE----- or -----BEGIN PRIVATE KEY-----. DER, PFX, and JKS files are binary — they won't display sensibly in a text editor, and you'd typically identify them by file extension or by attempting the appropriate OpenSSL/keytool command and checking for a format error, which usually names the format it expected.
Bundling versus converting: a distinction worth keeping straight
Some of these operations are pure format conversions (PEM to DER, and back), while others — like producing a PFX — are actually bundling multiple separate pieces (certificate, key, and often the CA chain) into one container file. Confusing the two is a common source of errors: a "conversion" command that fails with a complaint about a missing key or missing intermediate is usually not a broken conversion, but an attempt to bundle something without providing all the pieces the target format expects to contain.
Why understanding the underlying ASN.1/DER structure helps when conversions go wrong
When a conversion command fails with a cryptic parsing error, understanding that PEM is just base64-encoded DER wrapped in header lines often reveals the actual problem, commonly a corrupted base64 block or mismatched header/footer lines from a copy-paste error, rather than a genuine format incompatibility.
What to do when a conversion command produces an unexpected error message
Checking the input file's actual format first, confirming it's genuinely the format you assume it is via a text editor or the `file` command, catches the common case where a conversion command fails simply because the input wasn't the format expected, rather than an actual OpenSSL or tooling problem.
How different tools handle password-protected PFX files during conversion
Most PFX files are password-protected at creation, and every conversion command interacting with one will prompt for that password, or accept it via a `-passin` flag for scripted, non-interactive use — omitting the password entirely when the file is protected produces an authentication error rather than a format error.
What a complete PEM bundle actually needs to contain for most server software
A complete PEM bundle for most web server software needs your certificate followed by every intermediate certificate in the chain, concatenated in order from your certificate up toward (but not including) the root — omitting an intermediate, or including it in the wrong order, is the most common cause of a bundle that looks correct but doesn't validate properly.
How to verify a converted file is actually valid before deploying it
Running the appropriate OpenSSL inspection command against the converted output, `openssl x509 -text -noout` for a certificate or `openssl rsa -check` for a key, confirms the conversion produced a genuinely valid, parseable file before you deploy it, rather than discovering a conversion error only once it's already installed on a live server.
Why keeping the original, unconverted files as a backup is worth the minor storage cost
Keeping the original files you converted from, even after a successful conversion, costs negligible storage and provides an immediate fallback if the converted version later turns out to have an issue that wasn't apparent at conversion time — deleting source files immediately after conversion removes a safety net for very little benefit.
Why some enterprise software specifically requires Java's proprietary JKS format
Java-based enterprise software (many application servers, some Java-based load balancers) often expects certificates in Java KeyStore format rather than standard PEM or PKCS#12 — the `keytool` utility bundled with any Java installation handles converting into and out of this format, a step worth knowing about specifically if you're deploying to Java-based infrastructure.
What a corrupted or incomplete download looks like when you try to convert it
A certificate file corrupted during download or copy-paste typically fails conversion with a parsing error referencing unexpected characters or an incomplete structure — re-downloading the original file directly from its source, rather than trying to repair a corrupted copy, is almost always faster than debugging the specific corruption.
Why maintaining a personal reference sheet of conversion commands saves time long-term
Because certificate format conversion is an infrequent task for most people, the exact OpenSSL command syntax is easy to forget between uses — keeping a personal reference sheet of the specific commands you've used successfully before saves considerable time re-deriving the correct syntax from scratch each time the need arises.
What a quick closing checklist for format conversion looks like
Before trusting a converted file in production, confirm: the conversion command completed without errors, the resulting file passes OpenSSL's own inspection command, and you've kept the original source files as a backup in case anything about the converted version needs revisiting.
Why this skill remains relevant even as more platforms automate certificate handling
Even as managed platforms increasingly hide certificate management entirely, format conversion remains a genuinely useful skill for the recurring cases that fall outside fully automated platforms — legacy enterprise software, specific hardware appliances, and custom infrastructure that still expects a specific, manually-provided format.
What a quick reference table of common conversions looks like
PEM to DER: openssl x509 -outform der. DER to PEM: openssl x509 -inform der -outform pem. PFX to PEM: openssl pkcs12 -in file.pfx -out file.pem -nodes. PEM to PFX: openssl pkcs12 -export -out file.pfx -inkey key.pem -in cert.pem — the four conversions covering the large majority of real-world format needs.
How to handle a certificate chain that needs splitting into separate files
Some software expects the certificate and each intermediate as entirely separate files rather than one combined bundle — the csplit or awk command-line tools can split a combined PEM bundle back into individual files at each BEGIN/END CERTIFICATE boundary if your specific software requires that separated structure.