PKCS#12 (PFX) Files Explained: Bundling, Importing and Inspecting

Linux tooling treats certificate, key and chain as three files; Windows, IIS and most client platforms want one password-protected container. That container is PKCS#12 — extension .pfx or .p12 — and knowing how to build and inspect it saves an hour on every Windows-oriented deployment.

What a PFX contains

• The end-entity certificate.
• The private key, encrypted with the export password.
• The intermediate CA certificates you supply — the full chain up to (but usually excluding) the root.
• Optionally friendly names, attributes and extra certificates.

The export password protects only the key inside; the certificates themselves are public material. Anyone holding the file still needs the password to extract the key, which is why password discipline on PFX files is key discipline.

Building a bundle

The canonical openssl invocation, given key.pem, cert.pem and chain.pem (intermediates concatenated, leaf first):

openssl pkcs12 -export -out bundle.pfx -inkey key.pem -in cert.pem -certfile chain.pem

It will prompt for an export password; use something strong and record it in your secret store, because there is no recovery. Two flags worth knowing: -name "Friendly Name" sets the label Windows shows in the certificate store, and -macalg sha256 avoids legacy MACs that newer Windows builds warn about. If your key is encrypted and the target system dislikes that, decrypt it first with openssl rsa -in key.pem -out key-nopass.pem and handle the plaintext key with corresponding care.

Importing to Windows and IIS

1. Open certlm.msc (Local Machine store), import the PFX under Personal → Certificates, and mark the key as exportable only if you must keep a backup.
2. In IIS, either import during binding creation or refresh the existing binding — the new certificate appears automatically once imported with its private key present.
3. If the chain is missing after import, the -certfile part was omitted; Windows then fails the chain on strict clients even though the leaf looks fine.

Inspecting an existing PFX

Before trusting a file someone emailed you, look inside it:

openssl pkcs12 -in bundle.pfx -info -nokeys
openssl pkcs12 -in bundle.pfx -clcerts -nokeys | openssl x509 -noout -subject -dates

The first lists contents without exposing the key; the second extracts the leaf and shows its subject and validity. Check that the subject matches the domain you expect and that expiry is not next Tuesday — PFX files have a way of being older than everyone assumes. If the file contains a key you did not expect, or an extra certificate chain from a different CA, stop and ask where it came from; a PFX of unknown provenance should be treated as untrusted input.

When you need to produce or unpack one of these quickly, the PFX builder on WhoDNS combines key, certificate and chain into a PKCS#12 bundle from the browser, and the related decode tool reads an existing PFX back into plain fields — both sides of the same workflow without remembering openssl syntax.