If you’ve ever tried to install an SSL certificate and hit a wall because the server expects .crt but your CA sent you .pem, you know how frustrating this rabbit hole can get. I’ve been there more times than I’d like to admit. The good news is that once you understand what these formats actually are — not just their extensions — everything clicks into place.
What’s Actually Inside an SSL Certificate File
An SSL certificate is fundamentally a block of data structured according to the X.509 standard. That data contains your public key, your domain information, the CA’s signature, validity dates, and a few other fields. The format just describes how that binary data is encoded and stored on disk.
Extensions like .crt, .pem, .cer, .key are often misleading because they don’t always correspond to the encoding format. A .crt file can be either PEM or DER encoded. A .pem file might contain just the certificate, or the certificate plus the private key, or an entire chain. This is why just looking at the file extension often tells you nothing useful.
PEM — The Most Common Format You’ll Encounter
PEM stands for Privacy Enhanced Mail, which is a name that made sense in the 1990s and means very little today. The format uses Base64 encoding of the DER data, wrapped in -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- headers.
Open any .pem file in a text editor and you’ll see something like this:
-----BEGIN CERTIFICATE-----
MIIFazCCA1OgAwIBAgIRAIIQz7DSQONZRGPgu2OCiwAwDQYJKoZIhvcNAQELBQAw
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
...
-----END CERTIFICATE-----PEM is the default format on Linux systems, and it’s what Nginx, Apache, HAProxy, and most open-source servers expect. One major advantage is that you can stack multiple certificates in a single file — put your domain cert first, followed by intermediate certs — to create a certificate chain bundle. This is often called a “full chain” or “bundle” file.
Private keys in PEM format look the same but have different headers:
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----Or, for RSA-specific keys:
-----BEGIN RSA PRIVATE KEY-----
...
-----END RSA PRIVATE KEY-----When Files Use .crt, .cer, .key Extensions
These are just conventions. .crt and .cer usually contain the certificate itself (not the private key). .key contains the private key. But whether they’re PEM or DER encoded depends on who generated them.
A quick way to check: if you can open the file in a text editor and see readable characters (not garbage binary), it’s PEM. If it’s unreadable binary, it’s DER.
DER — Binary Encoding for Java and Windows
DER (Distinguished Encoding Rules) is the raw binary format. No Base64, no headers — just binary-encoded ASN.1 data. Files typically use .der or .cer extensions.
Java applications historically prefer DER format, and it’s also common in Windows environments. The .cer extension in Windows Explorer almost always means DER, though Windows can actually work with both.
You can’t open a DER file in a text editor meaningfully. If you try, you’ll see binary garbage. The file will start with bytes 30 82 (which is the ASN.1 sequence header) if you look at it with a hex editor.
DER files can only contain one certificate. Unlike PEM, you can’t bundle multiple certs together in a single DER file.
PFX / PKCS#12 — The Windows Bundle Format
PFX (also called P12 or PKCS#12) is a container format that bundles the certificate, the private key, and optionally the certificate chain into a single password-protected file. Extensions are .pfx or .p12.
This format is the native format for Windows IIS, Microsoft Azure, and some Cisco products. When a Windows admin asks you for “the certificate,” they often mean a PFX file because it has everything in one place and they don’t have to deal with separate key files.
The password protection is mandatory — you cannot create a PFX without setting a password, though you can set an empty string as the password, which is technically valid but offers no protection.
I usually avoid distributing PFX files over email even though they’re password-protected. The private key is inside, and if someone cracks the password (or you used “123456”), they have full access.
PKCS#7 / P7B — Certificate Chains Without Keys
The .p7b format (PKCS#7) is used specifically for certificate chains. It contains the certificate and intermediate CA certificates but never includes the private key.
You’ll mostly encounter this format when downloading certificates from Windows Certificate Manager or certain corporate CAs. Apache and Tomcat can use P7B format, though PEM is more common in practice.
CSR — Not a Certificate, But Often Confused for One
A Certificate Signing Request (.csr) is not a certificate — it’s what you generate before you have a certificate. It contains your public key and domain info, and you submit it to a CA. They sign it and send back the actual certificate.
CSR files are PEM-encoded by default:
-----BEGIN CERTIFICATE REQUEST-----
...
-----END CERTIFICATE REQUEST-----Once you have your certificate, you don’t need the CSR anymore, though keeping it around for reference doesn’t hurt.
Comparing the Formats at a Glance
| Format | Encoding | Can Include Private Key | Multi-Cert Bundle | Typical Use |
|---|---|---|---|---|
| PEM | Base64 | Yes | Yes | Linux, Nginx, Apache |
| DER | Binary | No | No | Java, Windows |
| PFX/P12 | Binary | Yes (required) | Yes | Windows IIS, Azure |
| P7B | Base64 or Binary | No | Yes | Windows cert chains |
Checking What Format a File Actually Is
When someone sends you a certificate file and you’re not sure what format it’s in, a few commands help immediately:
# Check if it's PEM-readable
file certificate.crt
# Try to read it as PEM
openssl x509 -in certificate.crt -text -noout
# If that fails, try DER
openssl x509 -in certificate.crt -inform DER -text -noout
# Check if it's PKCS#12
openssl pkcs12 -in certificate.pfx -nooutThe openssl commands will give you clear errors if the format doesn’t match, which is usually enough to figure out what you’re working with. Read more in post converting SSL certificates between formats
Understanding formats is the foundation for all the conversion and installation work that follows. Once you know that PEM is just Base64-encoded DER, and that PFX is just an encrypted container, the conversion commands stop looking like magic spells and start making actual sense.