How to Combine a Certificate and Private Key Into a PFX File

Some platforms (notably IIS and Java-based servers like Tomcat) expect a combined PFX/PKCS12 file rather than separate PEM certificate and key files, which is the more common format CAs issue by default.

openssl pkcs12 -export -out yourcert.pfx \
  -inkey yourkey.pem -in yourcert.pem -certfile ca-bundle.pem

This bundles your certificate, private key, and the CA intermediate bundle into a single password-protected PFX file, ready to import into IIS's Server Certificates panel or convert further into a Java keystore for Tomcat.

What to do if the resulting PFX file fails to import into Windows or another target system

An import failure often points to a mismatch between the certificate and key (verify they match using the modulus comparison technique covered in our related certificate troubleshooting guide) or a missing intermediate certificate that should have been included in the PFX bundle.

How to set a strong export password when creating the PFX file

Using a notably random, sufficiently long password when creating a PFX file, rather than a simple or reused one, matters since the PFX format's protection is only as strong as the password chosen — a weak password undermines the format's built-in protection regardless of how strong the underlying certificate's cryptography is.

What including intermediate certificates in the PFX bundle actually accomplishes

Including the full certificate chain, not just your end-entity certificate, in the PFX bundle ensures whatever software imports it has immediate access to the complete chain needed for validation, rather than requiring a separate step to add intermediates after import.

How to verify the PFX file was created successfully before deploying it

Running openssl pkcs12 -info against the newly created file and providing the export password confirms it contains the expected certificate and key without errors, verifying success before deploying it to a production system where a corrupted file would cause a harder-to-diagnose failure.

Why some target systems expect a specific PFX format version or encryption algorithm

Some older enterprise software expects PFX files using specific, sometimes outdated encryption algorithms for backward compatibility reasons — if a target system rejects a PFX file created with OpenSSL's modern defaults, checking that system's specific documented format requirements and adjusting the OpenSSL command's algorithm flags accordingly usually resolves it.

What to do if OpenSSL reports the certificate and key don't match during PFX creation

OpenSSL will refuse to combine a mismatched certificate and key pair, reporting an error rather than silently creating an invalid PFX file — this error means you have the wrong key for that specific certificate, worth double-checking you're referencing the correct, matching pair of files.

How to include a friendly name for the certificate within the PFX file

Adding the -name flag with a descriptive label when creating a PFX file with OpenSSL embeds a human-readable friendly name, making the certificate easier to identify later when browsing a certificate store containing multiple certificates, particularly useful in Windows certificate management interfaces.

A closing note on when you'll in fact need this specific conversion

This specific conversion direction, from separate PEM files into a combined PFX, comes up most often when deploying to Windows-based infrastructure or Java-based enterprise software, both of which commonly expect this bundled format rather than separate certificate and key files.