Importing pfx (PKCS12) certificate fails on Fedora but succeeds on Windows 11


I am trying to import a PKCS12 pfx file into Firefox, but it refuses to do so complaining that either the file is corrupted or the password is wrong. However, neither of those assumptions is true: I am able to extract the certificate from the command line using

openssl pkcs12 -in <file>.pfx -clcerts -nokeys -legacy -out certificate.crt

(I had to add the -legacy option otherwise it would not work)

Chromium and seahorse also fail – seahorse is able to decrypt the file and look at its contents (a RSA key and the certificate per se), but the “import” button remains disabled.

The curious thing is: the same version of Firefox running on a Windows 11 VM is able to import the pfx directly. This (and the need to add the -legacy parameter) leads me to think something might be wrong system-wide.

Any hints on what I need to do?

Some additional info: I am also unable to import a certificate generated last year, which I had already decrypted successfully on an older version from Fedora (and which I am still using on Firefox on this very same F40 setup). It does seem that something has changed on the last 12 months on modern Linux versions that is preventing me from doing the same import – perhaps stricter security standards?

… and some more info: running openssl pkcs12 -legacy -in <file>.pfx -info shows that the private key was generated with

MAC: sha1, Iteration 1024
MAC length: 20, salt length: 20
PKCS7 Data
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 1024

and the certificate was generated with

PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 1024

I did some research online, and it seems this combination (PKCS7 + CBC + 1024 key length) is insecure, so this is probably the reason why it is being refused.

1 Like

It is best best to re-generate the keys and re-issue the certificates using modern security standards and algorithms.

If this task is outside your scope, report the issue to the responsible IT or security department.

It may still be possible to work around the problem using the legacy crypto-policy, but the more time passes, the less likely it will work:

Thanks @vgaetera , always lending a hand to help :wink: :clap:

I did manage to workaround the issue. I’ll post here what I had to do so that it might be helpful to others.

Following the instructions here, I was able to extract the certificate and private key from the .pfx file (had to use the -legacy parameter, though)

openssl pkcs12 -legacy -in <file>.pfx -clcerts -nokeys -out certificate.crt
openssl pkcs12 -legacy -in <file>.pfx -nocerts -out encrypted.key
openssl rsa -in encrypted.key -out private.key

Then I used openssl to generate a new PKCS12 file, with the default encryption parameters:

openssl pkcs12 -export -in certificate.crt -inkey private.key -out certificate.p12

After that, both Firefox and Chromium were able to import the newly generated certificate.p12 file :raised_hands: :sweat_smile:

For the curious ones, the new files were encrypted with

MAC: sha256, Iteration 2048
MAC length: 32, salt length: 8
PKCS7 Encrypted data: PBES2, PBKDF2, AES-256-CBC, Iteration 2048, PRF hmacWithSHA256


PKCS7 Data
Shrouded Keybag: PBES2, PBKDF2, AES-256-CBC, Iteration 2048, PRF hmacWithSHA256

So, another point to Linux for raising the bar in terms of security (Windows 11 didn’t bother to handle such insecure files – no surprise here… :unamused: ).

And shame on my certificate issuer for using such poor security standards!