How to Seamlessly Change the Format of Digital Certificates?

Key Takeaways

• PEM, DER, PFX/PKCS#12, and P7B/PKCS#7 are the four certificate formats you will convert between most often, and each maps to specific server platforms.
• OpenSSL handles every common conversion path with a single command; renaming a file extension only works within the PEM family (.pem, .crt, .cer, .key).
• Back up the original files and record a checksum before converting anything that includes a private key.
• Validate every converted certificate with OpenSSL before deploying it, and keep the rollback path ready.
• Manual conversion does not scale past a handful of certificates; CertSecure Manager automates format conversion and export as part of the certificate lifecycle.

Published: July 2021. Updated: August 2026. Reviewed by Encryption Consulting’s PKI Operations team.

What Digital Certificate Formats Exist, and What Does Each One Mean?

A digital certificate is the same underlying X.509 data structure no matter how it is stored; the format only changes how that data is encoded on disk and what it is bundled with. Every enterprise PKI operator runs into four formats regularly:

• PEM (Privacy-Enhanced Mail): a Base64 ASCII-encoded text format bounded by “—–BEGIN CERTIFICATE—–” and “—–END CERTIFICATE—–” lines. A PEM file can hold a certificate, a private key, or a full chain, one after another. Common extensions: .pem, .crt, .cer, .key, .ca-bundle. Used by Apache, Nginx, and most OpenSSL-based applications.
• DER (Distinguished Encoding Rules): the binary encoding of the same X.509 data, with no BEGIN/END header lines. Because it is binary, you cannot safely edit or concatenate a DER file in a text editor. Common extensions: .der, .cer. Used by Java keystores and some Windows binary import flows.
• PFX/PKCS#12: a password-protected binary archive (PFX is the Windows name for a PKCS#12 file) that bundles the server certificate, the intermediate chain, and the private key in one file. Common extensions: .pfx, .p12. Used by Windows, IIS, and Exchange for import and export.
• P7B/PKCS#7: a Base64-encoded certificate chain format bounded by “—–BEGIN PKCS7—–” and “—–END PKCS7—–” lines. It cannot store a private key, only certificates and a Certificate Revocation List (CRL). Common extensions: .p7b, .p7c. Used by Java Tomcat and Windows chain-import workflows.

No format is more secure or more correct than another; the certificate’s cryptographic content is identical in every one. The format you need is dictated entirely by what the destination platform expects, which is why format conversion is a routine operational task rather than a security decision.

What Do You Need Before Converting a Certificate Format?

Confirm these five items before running any conversion command against a certificate that is live on a production system.

• OpenSSL installed and its version confirmed. Run openssl version first. OpenSSL 3.x moved older PKCS#12 encryption (RC2, 3DES) into a legacy provider, so a PFX exported years ago may need the -legacy flag added to the command.
• Access to the private key when converting to or from PFX/PKCS#12, and confirmation of who is authorized to handle it.
• A verified backup of the original certificate and key files, copied to a separate location before any command runs, plus a recorded checksum (see the logging section below).
• The destination system’s exact required format, confirmed against the decision table further down this page rather than assumed.
• A staging environment or maintenance window to test the converted file before it replaces the certificate on a production service.

How Do You Convert Between Certificate Formats Using OpenSSL?

Each conversion below is a single OpenSSL command. Run every command against your backup copy, not the file currently in use by a live service.

Step-by-Step: Convert PEM to DER

1. Copy certificate.pem to a working directory and confirm it opens as readable Base64 text.
2. Run: openssl x509 -outform der -in certificate.pem -out certificate.der
3. Confirm certificate.der was created and is binary (it will not open cleanly as text).

Step-by-Step: Convert DER to PEM

1. Confirm the source file is genuinely DER-encoded binary before running the command; a .cer extension can be either PEM or DER.
2. Run: openssl x509 -inform der -in certificate.der -out certificate.pem
3. Open certificate.pem in a text editor and confirm it now shows “—–BEGIN CERTIFICATE—–“.

Step-by-Step: Convert PEM to PFX (PKCS#12)

1. Confirm you have the certificate (certificate.crt), its matching private key (privateKey.key), and, if available, the CA chain file (CAcert.crt).
2. Run: openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CAcert.crt
3. Enter a strong export password when prompted. The -certfile CAcert.crt flag is optional; use it to bundle the intermediate chain into the PFX so the destination system does not need it separately.

Step-by-Step: Convert PFX to PEM

1. Confirm you have the PFX file and its export password.
2. Run: openssl pkcs12 -in certificate.pfx -out certificate.pem -nodes
3. OpenSSL will prompt for the PFX password, then write the certificate, chain, and unencrypted private key into a single PEM file. Open it in a text editor and split it into separate certificate and key files if the destination platform requires that, keeping each “—–BEGIN—–“/”—–END—–” block intact.
4. Drop -nodes if you want the extracted private key to stay encrypted with a passphrase inside the PEM output.

For the P7B/PKCS#7 chain format: convert PEM to P7B with openssl crl2pkcs7 -nocrl -certfile certificate.cer -certfile CAcert.cer -out certificate.p7b (the second -certfile is optional, used to bundle an additional chain certificate), and extract certificates from a P7B back to PEM with openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer. Because P7B cannot hold a private key, converting P7B to PFX is a two-step process: extract the certificates with the command above, then run openssl pkcs12 -export -in certificate.cer -inkey privateKey.key -out certificate.pfx -certfile CAcert.cer using the private key you already have on hand.

One shortcut is safe to use: renaming a file between .pem, .crt, .cer, and .key changes nothing about the underlying Base64 encoding, so a plain rename works within that family. It does not work across families. Renaming a PEM file to .der does not make it binary DER, and renaming a certificate file to .pfx does not bundle in a private key. Anywhere the encoding or the file’s contents genuinely need to change, run the matching OpenSSL command above instead.

How Do You Validate a Converted Certificate?

Validate the output before it ever reaches a production service. Run these checks against the converted file:

• Confirm the certificate parses and check its details: openssl x509 -in certificate.pem -text -noout (use -inform der for a DER file). Review the subject, issuer, validity dates, and Subject Alternative Names against what you expect.
• Verify the chain of trust: openssl verify -CAfile ca-bundle.pem certificate.pem should return certificate.pem: OK.
• Confirm the certificate and private key are a matching pair by comparing their moduli: openssl x509 -noout -modulus -in certificate.pem | openssl md5 and openssl rsa -noout -modulus -in privateKey.key | openssl md5 must produce identical output.
• Inspect a PFX bundle without exporting its contents: openssl pkcs12 -info -in certificate.pfx -noout, then confirm the certificate, chain, and key are all present.

Only after every check above passes should the converted file be deployed, and even then, deploy it in a maintenance window with the ability to revert immediately.

What Is the Rollback Procedure If a Conversion Breaks Something?

Keep the original certificate and key files untouched in a separate, access-controlled backup location for the entire change window, and do not overwrite or delete them until the converted file has been live and verified in production for a defined observation period (commonly 24 to 72 hours). If a service fails to start, presents a chain error, or a client rejects the new certificate, roll back by restoring the original file to its original path, reverting any configuration change that pointed to the new format, and restarting the affected service, then re-run the validation checks above against the restored original before closing the incident. Never attempt a second live conversion attempt to “fix” a failed deployment; roll back first, diagnose against the backup copy, and retry in the next maintenance window.

What Should You Log During a Certificate Format Change?

Treat every certificate format change as an auditable event, not a one-off command. Record the following for each conversion, whether it is done manually or through automation:

• Timestamp, operator identity, and the change or ticket number authorizing the work.
• Source format, target format, and the exact OpenSSL command executed (redacting any password from the log).
• A checksum (for example, sha256sum certificate.pem) of both the original and the converted file, so the conversion can be proven not to have altered the certificate’s identity.
• The target system and service the converted certificate was deployed to, and the result of each validation check.
• Confirmation the original file was retained and where, for rollback purposes.

This log is what an auditor asks for under ISO/IEC 27001:2022 or SOC 2 change-management controls, and it is the difference between a defensible operational change and an unexplained certificate replacement on a production system.

What Are the Most Common Certificate Conversion Errors, and How Do You Fix Them?

Error or Symptom	Likely Cause	Fix
OpenSSL repeatedly prompts for a password you do not have	Source PFX or PEM private key is passphrase-protected and the passphrase was not provided or is unknown	Locate the original passphrase from whoever issued the certificate; if it is genuinely unrecoverable, re-issue the certificate rather than attempting to bypass the password
“unable to load certificate” or “no start line” errors	The file is not actually PEM (often a DER file with a .cer or .pem extension, or a corrupted download)	Confirm the real encoding with a hex/text check, then use the matching -inform der or -inform pem flag instead of guessing
“unable to get local issuer certificate” during openssl verify	The intermediate CA certificate is missing from the chain bundle passed to -CAfile	Rebuild the CA bundle with the correct intermediate and root certificates, in order, and re-run verification
PKCS#12 export or import fails on OpenSSL 3.x for an older PFX file	The PFX was encrypted with RC2 or 3DES, which OpenSSL 3.x moved into a legacy provider	Add the -legacy flag to the openssl pkcs12 command, or re-export the PFX with a current cipher once you can decrypt it
Certificate and private key modulus values do not match after conversion	Wrong key file was used, or the wrong certificate was converted	Re-run the conversion using the confirmed correct key/certificate pair from the backup, and re-check the modulus comparison
Destination platform still rejects the converted certificate	Format matched but the required chain (intermediate certificates) was not bundled into the output	Re-run the export with -certfile pointing at the full intermediate chain, and confirm with openssl pkcs12 -info or openssl x509 -text that the chain is present

What Operational Outcomes Should You Expect From a Well-Run Conversion Process?

A certificate format change that follows the prerequisites, validation, rollback, and logging steps above should produce measurable results, not just “it worked”:

• Zero unplanned downtime on the target service, because the converted certificate was validated against the platform’s requirements before deployment, not after.
• A 100 percent validation pass rate before any converted certificate reaches production, verified with the openssl verify and modulus-match checks above.
• A complete, auditable change record for every conversion, satisfying change-management evidence requests without extra reconstruction work.
• A documented mean time to rollback under the observation window defined for the change, rather than an ad hoc scramble if something breaks.

Which Certificate Format Does Each Platform Require?

Format	Encoding	Typical Use Case	Common Systems
PEM (.pem, .crt, .cer, .key)	Base64 ASCII text	Separate certificate, chain, and key files served directly by the web server	Apache, Nginx, most Linux/Unix services, OpenSSL-based applications
DER (.der, .cer)	Binary	Applications that require the raw binary X.509 structure with no header lines	Java keystores (via keytool), some embedded and IoT systems, certain Windows binary import flows
PFX/PKCS#12 (.pfx, .p12)	Binary, password-protected bundle	Single-file transfer of certificate, chain, and private key together	Windows Server, IIS, Exchange, macOS Keychain import, Kubernetes TLS secrets built from a bundle
P7B/PKCS#7 (.p7b, .p7c)	Base64 ASCII text, no private key	Distributing a certificate chain without exposing any key material	Windows and IIS chain import, Java Tomcat trust store import

What Are the Limitations of Manual Certificate Format Conversion?

The OpenSSL runbook above is reliable for one certificate or a small, planned batch, but it has real limits at scale. Private key material passes through shell commands and, if you are not careful, shell history and script logs, which is an unnecessary exposure risk. OpenSSL’s own behavior changes between major versions, such as the 3.x legacy-provider requirement for older PKCS#12 files, and a script written against one version can fail silently against another. Manual conversion has no built-in audit trail; the logging discipline above has to be enforced by the operator every single time, and it is the first thing skipped under deadline pressure. None of this scales to the thousands of certificates a mid-size enterprise typically manages across multiple platforms and cloud environments.

What Would Encryption Consulting Recommend?

For a handful of certificates, the OpenSSL commands above are the right tool. Past that, manual format conversion becomes the operational risk this runbook exists to control: private keys handled by hand, validation steps that depend on an individual remembering to run them, and no single source of truth for which certificate is in which format on which server.

CertSecure Manager removes the manual step entirely: it issues, renews, and exports certificates directly in the format the target platform requires, whether that is a PEM bundle for Nginx or a password-protected PFX for IIS, without an operator ever touching a private key on the command line. Every export is logged automatically, chain bundling is handled for you, and format mismatches are caught before deployment rather than discovered as a production outage. Where certificates are issued through a managed CA rather than an on-premises one, PKI-as-a-Service extends the same automated issuance and export model without operating the CA infrastructure yourself. If you want to check a certificate’s contents before or after a conversion without installing anything, EC’s free OpenSSL CSR and Certificate Decoder and ASN.1 CSR and Certificate Decoder tools parse and display certificate fields directly in the browser. Encryption Consulting is ISO/IEC 27001:2022 and SOC 2 certified, so the same audit trail this runbook asks you to build by hand is a built-in feature of CertSecure Manager’s certificate lifecycle logs.

For a related, real-world walkthrough that uses these same OpenSSL commands during a certificate renewal, see Renewing Certificate on Apache with CertSecure Manager. For a deeper, single-conversion walkthrough of the PFX-to-PEM path specifically, see How to Seamlessly Convert PFX Encoded Certificate File to PEM Format Using OpenSSL.

Frequently Asked Questions

What is the difference between PEM and DER certificate formats? PEM (Privacy-Enhanced Mail) is a Base64 ASCII-encoded format bounded by “—–BEGIN CERTIFICATE—–” and “—–END CERTIFICATE—–” lines, commonly used by Apache, Nginx, and OpenSSL-based applications. DER (Distinguished Encoding Rules) is the binary form of the same X.509 data with no header lines, commonly required by Java keystores and some Windows binary imports. You can convert between them with a single OpenSSL command in either direction.

Can I convert a certificate format without OpenSSL? For PEM-family formats (.pem, .crt, .cer, .key), renaming the file extension works because the underlying Base64 encoding does not change. You cannot convert to or from a genuinely different encoding, such as PEM to DER or PEM to PFX, by renaming alone, because those formats use different byte-level encoding or bundle additional data like a private key. OpenSSL, or an equivalent library, is required for a true format conversion.

Is it safe to convert a PFX file that contains a private key? Yes, if you handle the private key with the same care you would give the original file. Keep the PFX password and any exported PEM private key out of shell history and version control, restrict file permissions to the account that needs them, and delete decrypted intermediate files once the conversion and validation are complete.

Which certificate format does IIS or Windows need versus Apache or Nginx? Windows Server, IIS, and Exchange typically require a PFX (PKCS#12) file because it bundles the certificate, its chain, and the private key into one password-protected file. Apache and Nginx expect separate PEM-encoded files for the certificate, chain, and private key. Converting between the two is one of the most common certificate format changes operations teams perform during a server migration.

What should I do if OpenSSL prompts for a password I do not have during conversion? The prompt means the source file is encrypted, typically a PFX file or a PEM private key with a passphrase. If the password is genuinely unknown, you cannot decrypt the file with OpenSSL, and you will need to re-issue the certificate from the certificate authority or the system that originally generated it. Never attempt to brute-force or bypass the password on a production key.

Conclusion

Changing a digital certificate’s format is a routine operational task once you treat it as a runbook instead of a one-off command: confirm the destination platform’s real requirement, back up the originals, run the correct OpenSSL command, validate the output, and log what changed. That discipline is what keeps a certificate migration from becoming an outage. As the number of certificates you manage grows past what one operator can track safely by hand, automating issuance and export in the correct format for every platform, with CertSecure Manager or an equivalent PKI-as-a-Service platform, is what keeps this process reliable at scale.

References

• OpenSSL, OpenSSL Documentation
• IETF, RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile
• IETF, RFC 7292: PKCS #12: Personal Information Exchange Syntax v1.1