Certificate Export Formats Explained (and When to Use Them)
Certificate management gets messy fast when different platforms expect different file formats,
containers, and chain structures. This is especially common when teams use a certificate manager
(like Venafi) and then need to import the results into platforms such as:
- Cisco ISE (Identity Services Engine)
- F5 BIG-IP Load Balancers
- Palo Alto Firewalls
- Cisco Routers and Switches
This post breaks down the most common certificate formats you see in export dialogs (Base64/OpenSSL,
PKCS#12, PKCS#7, DER, PKCS#8, JKS), what each format actually is, and why you would choose—or avoid—it.
We’ll also cover a common mistake: exporting a private key when you only need a
trusted CA certificate.
- Trusted CA store import (Root / Intermediate CA certs only) → public certs only, no private key
- Identity/server certificate import (the device’s own cert) → usually includes private key
Why this matters in Cisco ISE (and similar platforms)
A common scenario is exporting a certificate from Venafi and importing it into Cisco ISE’s
Trusted Certificates store. If the export includes a private key or the wrong format/container,
ISE may throw an error like Invalid File.
For Trusted Root / Intermediate CA imports, Cisco ISE expects a clean certificate file
(public cert only), typically PEM/Base64 text. If you export a PKCS#12 file (.pfx/.p12) and then simply
“base64 encode” it, you are not converting it into a PEM certificate—you are only base64-encoding the entire
binary container.
Export CA certs as PEM / Base64 (OpenSSL) with no private key.
The Most Common Certificate Formats (What They Are)
| Format | Typical Extension(s) | Text or Binary | Can Include Private Key? | Common Use |
|---|---|---|---|---|
| Base64 (OpenSSL) / PEM | .pem, .crt, .cer, .txt, .key | Text | Yes (if exporting key separately or in same file) | Most interoperable format for certs and keys |
| DER | .der, .cer | Binary | No (for certificate DER file) | Binary X.509 certificate format |
| PKCS#7 | .p7b, .p7c | Text or Binary | No | Certificate chain bundles (no private key) |
| PKCS#12 | .pfx, .p12 | Binary | Yes | Identity cert + private key + chain in one password-protected bundle |
| PKCS#8 | .key, .pem | Text or Binary | Yes (key format) | Private key encoding format (not primarily a cert format) |
| JKS (Java Keystore) | .jks | Binary | Yes (keystore entry dependent) | Java applications / middleware keystore |
Format-by-Format Breakdown (When to Choose or Avoid)
1) Base64 (OpenSSL) — PEM
This is the “human-readable” text format most admins recognize because it contains blocks like:
-----BEGIN CERTIFICATE----- MIIF... -----END CERTIFICATE-----
PEM can also store private keys, CSRs, and chains—so the content matters, not just the extension.
Why choose it:
- Highly portable across vendors
- Easy to inspect in Notepad / any text editor
- Perfect for trusted CA imports (Root / Intermediate)
- Easy to split chain bundles into individual cert files
Why avoid it:
- Can be confusing if cert + key + chain are all mixed in one file
- Some GUI imports want a single cert per file and reject bundles
when importing Root and Intermediate certificates.
2) DER
DER is the binary form of an X.509 certificate. It contains the same certificate data as PEM, but not in
text form. You cannot easily inspect it in Notepad.
Why choose it:
- Some platforms/tools specifically request DER-encoded certs
- Compact binary format
Why avoid it:
- Not human-readable
- Harder to troubleshoot quickly
- Less convenient when you need to split bundles manually
If troubleshooting imports, PEM is usually easier than DER because you can immediately verify the file contents.
3) PKCS#7 (.p7b / .p7c)
PKCS#7 is commonly used to package certificates and chains, but not private keys.
It is often used in Windows-centric workflows and by some CA portals.
Why choose it:
- Useful for distributing certificate chains without private keys
- Can hold multiple certificates (Root + Intermediate chain)
Why avoid it:
- Not universally accepted in every network/security platform GUI
- Troubleshooting is less intuitive than PEM if the file is binary/encoded
- Not suitable when you need the private key
4) PKCS#12 (.pfx / .p12)
PKCS#12 is a password-protected binary container that can store:
- End-entity (leaf) certificate
- Private key
- Intermediate CA certificates
- Root CA certificate (optional)
Why choose it:
- Best for importing a device/service’s identity cert with private key
- Common for Windows/IIS, many appliances, and GUI-based imports
- Convenient “all in one” package
Why avoid it:
- Wrong choice for trusted CA-only imports in many cases
- Easy to accidentally include private key where it is not wanted
- Binary format is not easy to inspect
openssl base64 -in file.pfx -out file.base64 does not convert a PFX into a PEM certificate.It only base64-encodes the whole PKCS#12 container blob.
5) PKCS#8
PKCS#8 is primarily a private key format. It defines how private keys are encoded and stored
(encrypted or unencrypted). Some tools expose a “Base64 (PKCS#8)” export option, but that can be misleading if
the target system expects a certificate PEM and not key material.
Why choose it:
- Useful when a platform specifically requires a PKCS#8 private key
- Common in modern TLS/automation workflows and some software stacks
Why avoid it:
- Not the right choice for trusted CA certificate import workflows
- Can create confusion if “Include Private Key” is checked
- Easy to produce a file ISE/F5/Palo Alto rejects if they expect certificates only
6) JKS (Java Keystore)
JKS is Java’s legacy keystore format used by Java-based applications and middleware. It can contain trusted certs
and private keys under aliases.
Why choose it:
- Required by some Java apps, app servers, and middleware stacks
- Supports alias-based keystore organization
Why avoid it:
- Not a general-purpose format for network appliances
- Cisco ISE/F5/Palo Alto/Cisco routers typically do not want JKS for standard imports
- Harder to inspect without Java tooling (
keytool)
How This Applies to Common Platforms
| Platform | Trusted CA Import (Root/Intermediate) | Identity/Server Cert Import (with key) | Operational Recommendation |
|---|---|---|---|
| Cisco ISE | PEM / Base64 (OpenSSL) preferred for Trusted Certificates | Often PKCS#12 (.pfx/.p12) or PEM cert + key depending on workflow | For Trusted Store, export CA certs only; no private key |
| F5 BIG-IP | PEM cert imports are common for trusted CAs | PEM cert + key (and chain), or PKCS#12 in some workflows | Keep key/cert/chain clearly separated unless using a PFX intentionally |
| Palo Alto Firewalls | PEM/DER commonly used for trusted CA imports | PKCS#12 commonly used for cert+key imports; PEM also used | Use PEM for CA trust imports; use PFX only when importing private key |
| Cisco Routers / Switches | Often PEM/DER CA trustpoints (platform/version dependent) | Identity certs are typically tied to trustpoint/CSR workflow | For manual imports, keep CA certs as clean PEM/DER and validate chain order |
Exact import workflows vary by software version and feature (e.g., HTTPS management, EAP, SSL inspection, VPN, API certs).
The key pattern remains the same: Trusted CA store = public CA certs only, while
identity cert import = cert + private key.
Cisco ISE-Specific Example: Venafi Export Settings for Trusted Root / Intermediate
If you’re downloading certificates from Venafi for Cisco ISE Trusted Certificates (Root/Intermediate CA import),
use the settings below:
| Venafi Option | Recommended Setting | Why |
|---|---|---|
| Include Private Key | No (Unchecked) | Trusted stores should contain CA certs only, not private keys |
| Include Root Chain | Yes (Checked) | Includes Root + Intermediate(s) if desired |
| Chain Order | Either (Root first preferred for readability) | Order is usually not the deciding factor, but Root first is easier to verify manually |
| Format | Base64 (OpenSSL) | Provides PEM text format with BEGIN CERTIFICATE blocks |
It commonly introduces unnecessary private key/container complexity.
What the File Should Look Like (for Trusted CA Imports)
Good: Single PEM Certificate
-----BEGIN CERTIFICATE----- MIID... -----END CERTIFICATE-----
Good: PEM Bundle (Root + Intermediate) — may need splitting
-----BEGIN CERTIFICATE----- ...Root CA... -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- ...Intermediate CA... -----END CERTIFICATE-----
Bad for Trusted CA Store: File Contains Private Key
-----BEGIN CERTIFICATE----- ...cert... -----END CERTIFICATE----- -----BEGIN PRIVATE KEY----- ...key... -----END PRIVATE KEY-----
If a platform rejects a PEM bundle, split the file so each output file contains exactly one certificate block
and import them one-by-one (typically Root first, then Intermediate(s)).
Why Teams End Up Converting PKCS#12 (and How to Avoid It)
Teams often export PKCS#12 because it’s a familiar option and “seems like it includes everything.”
That’s useful for identity certificates, but it is often the wrong starting point for
trusted CA imports.
If your target is a trusted CA store:
- Export Base64 (OpenSSL) / PEM directly from the source system
- Do not include the private key
- Include the chain if needed, then split the PEM if the platform requires one cert per file
Quick Decision Matrix
| If you need to… | Choose this format | Avoid this |
|---|---|---|
| Import Root/Intermediate CAs into a trusted store (ISE/F5/Palo Alto/Cisco devices) | PEM / Base64 (OpenSSL) | PKCS#12 (unless absolutely necessary), PKCS#8 |
| Import a server/device identity cert with private key | PKCS#12 (.pfx/.p12) or PEM cert + key (platform dependent) | PKCS#7 alone (no private key) |
| Distribute a certificate chain without keys | PEM bundle or PKCS#7 | PKCS#12 (if keys are not needed) |
| Support a Java-only app/server keystore workflow | JKS (or PKCS#12 if app supports it) | Raw PEM only, if the app specifically requires a keystore |
Final Recommendations
- Start with the use case, not the format. Trusted CA import and identity cert import are different workflows.
- For trusted CA stores: use PEM / Base64 (OpenSSL), no private key.
- For identity certs with private key: use PKCS#12 (or PEM cert + key if the platform expects that).
- Inspect PEM files in a text editor before import to catch private key blocks or mixed content.
- Split bundles if needed when a platform rejects a multi-cert PEM.