Old P12 Fails on OpenSSL 3: Wrong Password or Legacy Cipher?

The import dialog takes your password, spins for a moment, and then says it cannot read the bundle. Nothing in that message tells you whether you mistyped the passphrase or whether the file was sealed with a cipher the client no longer ships. Those are different failures with different fixes, and picking wrong leads to a client downgrade that only postpones the decision. Watching the stage where the client stops separates them in about a minute.

What happens between the dialog and the certificate list

A .p12 file is a container, not a certificate. Inside are one or more certificate bags and a private-key bag that is encrypted with a key derived from your password, plus an integrity check called a MAC over the whole file. Opening it means verifying that MAC, decrypting the key bag, and matching the certificate to the key that comes out.

Password trouble arrives at the MAC step. Cipher trouble arrives later, when the key bag has to be unwrapped and the build doing the unwrapping has no implementation for the algorithm named in the file.

The second case is common on current systems because OpenSSL 3 moved a group of old algorithms into an optional legacy provider. Bundles exported by OpenSSL 1.x typically sealed the certificates with 40-bit RC2 and the private key with three-key Triple DES. A default OpenSSL 3 build still verifies the MAC with your correct password and then fails on the bag, so the password was never wrong and retyping it changes nothing.

Read the container without writing a key out

Ask the OpenSSL build on your own machine to parse the file and read the point where it gives up. Inspection with no output file leaves the key encrypted on disk, which is the only reason this step is safe to run on a shared host.

openssl pkcs12 -in vpn-identity.p12 -info -noout

On a legacy bundle with the correct password this prints bag attributes and then stops with digital envelope routines::unsupported. With a wrong password you get Mac verify error: invalid password? before any bag is read. The two messages point in opposite directions, which is exactly the information the client withheld.

If the failure is the unsupported-algorithm one, run the same command again with -legacy added and nothing else changed. That flag loads the legacy provider for that single process. It does not make the VPN client parse old bundles, it does not touch system-wide crypto policy, and it is a measurement rather than a repair, because the file still has to be replaced.

Which error means which stage

A short table keeps the three outcomes apart, and the wording matters more than where the dialog appeared.

Text like not enough data or header too long belongs to neither of the first two groups. That is a format problem: a DER file renamed to .pem, a copy mangled by an editor that rewrote line endings, or an incomplete download. Compare the checksum with the one the issuer sent before you start looking at ciphers.

Treat Mac verify error as evidence about the password only. It means the MAC computed from what you typed does not match the stored value, which happens with a typo, with a password cached from an earlier import, or with a file that was re-exported under a different passphrase. It says nothing about whether the algorithms inside are old.

Build a bundle the client can actually open

Once the legacy parser confirms the file is sound, the lasting fix is a replacement whose algorithms the target client supports: AES-256-CBC for the key and certificate bags, PBKDF2 with SHA-256 for derivation, and SHA-256 for the MAC. Your PKI administrator can export that from the same key material, and the certificate inside stays the one your servers already trust.

When you have to convert locally, ask the pkcs12 tool to re-seal the bags instead of dumping them first. Keep both passphrases out of your shell history by reading them from a file.

openssl pkcs12 -in vpn-identity.p12 -out vpn-identity-aes.p12 \
  -keypbe AES-256-CBC -certpbe AES-256-CBC -macalg sha256 \
  -passin file:old.pass -passout file:new.pass

A successful conversion says nothing about expiry, key usage, the private-key match, or whether the server trusts the issuing chain. Repackaging is a transport change, not a renewal, and each of those still needs its own check.

Skip any recipe that writes an unprotected intermediate key or an empty output password just because the client then accepted the file. A readable bundle with the protection stripped is a worse outcome than the import failure you started with.

Confirm the client imported the file you built

A clean parse in a terminal proves the container is valid. It does not prove the client selected it, because a leftover profile can keep pointing at the old file, and some clients cache an imported identity under a name you did not choose.

Print the identity you are about to import and compare it with what the client shows in its certificate view.

openssl pkcs12 -in vpn-identity-aes.p12 -clcerts -nokeys -passin file:new.pass \
  | openssl x509 -noout -subject -dates -fingerprint -sha256

Remove the stale profile entry first, then import. If the client logs the subject or fingerprint it loaded, match it against the line above; if it shows only a friendly name, check the expiry date instead, since that is harder to confuse with another certificate from the same issuer.

The PKCS12 reference lists the provider, passphrase and output options used here. Keeping the legacy provider out of the client environment is the point: measure with it, ship without it, and leave the private key protected on disk.