PEM, DER, PFX and P7B: When to Use Each Certificate Format
Understand common certificate containers, what may include a private key, and how to convert copies without overwriting the originals.
Certificate files can use several common formats and containers. The names PEM, DER, PFX/P12 and P7B describe different encodings or packaging choices, not different levels of trust.
Choosing the right format depends on what the receiving application expects and whether a private key must be included. Certificate Doctor can inspect and convert supported certificate files locally on Windows while keeping source files unchanged.
PEM: text encoding with familiar markers
PEM is a text representation that usually contains Base64 data between readable markers such as:
-----BEGIN CERTIFICATE-----
and:
-----END CERTIFICATE-----
A PEM file can contain one certificate, several certificates, or in some cases private-key material with different markers.
The .pem extension alone does not tell you exactly what is inside. Inspect the block types before copying or sharing the file.
PEM is common in servers, command-line tools and cross-platform workflows because it is text-based and easy to transport.
DER: binary certificate encoding
DER is a binary encoding of ASN.1 data. A DER certificate may use extensions such as .der, .cer or .crt depending on the ecosystem.
Because DER is binary, opening it in a text editor produces unreadable characters. That does not mean the file is corrupt.
DER is useful when a device or application specifically expects a binary certificate rather than PEM text.
Converting a certificate between PEM and DER normally changes the representation, not the certificate’s cryptographic identity. The certificate fields and signature should still describe the same certificate.
PFX / P12: certificate packaging that may include a private key
PKCS#12 containers commonly use .pfx or .p12. They can package:
- a leaf certificate;
- intermediate certificates;
- a private key;
- related metadata.
Because a PFX can contain a private key, treat it as sensitive until you have inspected it.
A password-protected PFX is not safe to publish merely because it has a password. Keep the file private and share passwords through an appropriate channel.
Certificate Doctor can open supported PFX/P12 files with the correct password and can create a new PFX using AES-256 protection and a new password.
P7B: certificate chains without private keys
P7B, often associated with PKCS#7 certificate bundles, is commonly used to package certificates and chains. It typically carries public certificates rather than a private key.
This can be useful when a system needs the leaf and intermediate certificates together but does not need private-key material.
Do not assume every PKCS#7-related file is the same kind of object. P7S signed-data containers and P7B certificate bundles serve different practical purposes even though both are related to PKCS#7/CMS structures.
Choose the target based on the receiving system
Do not convert simply because one extension looks more familiar.
Ask what the destination expects:
- a web server may ask for PEM certificate and key files;
- Windows software may import PFX/P12;
- a device may request DER;
- a certificate-chain import may accept P7B;
- a Java or application-specific keystore may require another workflow entirely.
Read the destination documentation first, then convert to that required format.
Private keys change the security stakes
Certificates are generally public information. Private keys are not.
Before converting anything, determine whether the source includes a private key. If you export a PEM “with key” or create a PFX, you may be creating a file that must be protected much more carefully than a certificate-only file.
Never paste private keys into support chats, public issue trackers or screenshots.
Certificate Doctor’s reports omit private-key material and passwords, but exported key-containing files are still your responsibility.
A safe conversion workflow
- Keep the source file unchanged.
- Inspect the source and confirm what objects it contains.
- Confirm whether a private key is present.
- Check the destination application’s required format.
- Choose the conversion that matches that requirement.
- Save to a new filename.
- Refuse overwrite if the destination already exists; choose another path instead.
- Reopen the exported file and inspect it.
- If a private key is included, store and transfer the result securely.
- Test it in the receiving application before deleting any source material.
Certificate Doctor is designed around new-file output rather than silently overwriting originals.
Example: PEM certificate to DER
Suppose a hardware tool asks for a .der certificate but you received a PEM certificate.
Inspect the PEM first to confirm it contains the certificate you expect. Convert that certificate to DER, save a new file, and reopen the DER result in Certificate Doctor.
Compare identifying fields such as Subject, Issuer, serial number and fingerprints. Representation changes should not turn it into a different certificate.
Example: certificate and key to PFX
Suppose an application needs a PFX import and you have a certificate chain plus the matching private key.
First verify that the private key matches the intended leaf certificate. Then create a new PFX with a strong new password and include only the appropriate chain material.
After export, reopen the PFX with the new password and inspect its contents before importing it into the target application.
Do not email the PFX and its password together just because the container is encrypted.
Example: PFX to PEM certificate and key
A server deployment may require separate PEM files.
If your authorized PFX contains the needed private key, export the certificate chain and key to new files. Protect the private-key file with filesystem permissions and deployment-secret handling appropriate to the environment.
Do not commit the key to a source repository.
If you only need the public certificate, do not export private-key material unnecessarily.
Password errors are information, not a reason to bypass protection
If a PFX cannot be opened with the password you have, stop and obtain the correct credential from the authorized source.
Do not upload a sensitive production PFX to random online “unlock” or conversion services to work around the problem.
Certificate Doctor processes supported files locally and reports password-protected or unreadable files rather than pretending inspection was complete.
Fingerprints help confirm you converted the intended certificate
After conversion, compare certificate fingerprints such as SHA-256 where appropriate. If the certificate itself is unchanged and only the encoding/container changed, the certificate fingerprint should identify the same certificate object.
Be careful about hashing the entire file: a PEM file and a DER file will have different file hashes because their byte representation differs. A certificate fingerprint calculated over the certificate representation is a different concept from a whole-file SHA-256 used to verify a download.
Converting does not fix trust, expiry or revocation
Changing PEM to DER, or PFX to another container, does not make an expired certificate current, repair an invalid issuer signature or make an untrusted root trusted.
Format and validation are separate concerns.
Certificate Doctor can inspect validity dates, key strength, signature algorithms and provided certificate chains, but it does not perform revocation, hostname validation or Windows system trust-store evaluation.
Keep an inventory when keys are involved
For production certificates, record where the private key came from, where authorized copies are stored and which systems use it. Uncontrolled conversions can create extra private-key copies that are forgotten later.
Delete temporary key-containing copies according to your organization’s process when they are no longer needed, while recognizing that ordinary file deletion is not a guarantee of cryptographic erasure from storage media or backups.
The practical rule is: inspect first, choose the target format for a real compatibility reason, keep the source, and treat any output containing a private key as sensitive material.