The workaround is easy: Change the passphrase , export, import and then set a longer passphrase again.

So I know of users who get pkcs#12 certificates, import them in firefox to export them so that they can be used in GnuPG. This is, and feels to users, stupid.

If you really want to do that -it has no security benefit for a passphrase protecting a private key. There are way easier methods to get to the private key than to brute force an even 32 character passphrase

Of course. But S/MIME CA's are stupid. They think longer is more secure and send such keys to their users. I know that V-PKI does this.

So to tl;dr;: Customers get such keys, the passphrase is out of their control. They have to workaround this limitation. Not good.

After years of using S/MIME I ran into a strange situation importing my new S/MIME certs to Kleopatra yesterday which ultimately led me to this thread.
My case is slightly different because my original passwords were short (2w7g9r1e and 2y8m7i5t), but it feels related so I thought I'd share nevertheless.

1. Purchased new S/MIME certs from Certum
2. Imported certs with supplied password into my encryption gateway without problems
3. When trying to import into Kleopatra I got an "invalid object" error
4. Tried importing into a Windows cert store with original password worked fine
5. Tried to import into Fairmail on my phone -> invalid password
6. Importing into Firefox was successful, with the original password (really glad to have found this thread and the FF workaround!)
7. Exported from Firefox with new password
8. Imported into Kleopatra and Fairmail with new password worked just fine

I purchased 2 certs, and both showed the exact same behaviour.
Means I am sorted, but I thought I'd still share because even though my issue and the fix is identical, the root cause is not password length, there seems to be something else at play?
By the way, I think Kleopatra could do with an "invalid password" message instead of "invalid object".

This thread refers to logs, but my journalctl is empty, if you want me to share some logs while the data is still around please let me know.

Please update to a recent gnupg versions. 2.3.3 or if you really need the LTS version use 2.2.40. Instead of using a log you can import on the command line:

gpgsm --import -v  MYP12FILE

if should show enough info.

I*m sorry, but I haven't found a way to determine what version of gnupg I am running. Just in case things got confused, I am not the thread opener, my version of gnupg is not whats been stated in the opening post but rather whatever is current on Arch Linux: Linux 6.0.11-arch1-1
I ran gpgsm --version though which returns this:
gpgsm (GnuPG) 2.2.40

Running the import command above with the password supplied by the vendor returns this:

gpgsm --import -v /media/data/NextCloud/testcert.pfx 
gpgsm: enabled compatibility flags:
gpgsm: data error at "shrouded_key_bag.pkcs5PBES2-params", offset 118
gpgsm: data error at "data.oid", offset 78
gpgsm: error at "bag.data", offset 49
gpgsm: error parsing or decrypting the PKCS#12 file
gpgsm: total number processed: 0

This has long been fixed in 2.4. Given that Libgcrypt has support for PBKDF2 we can back port this.

Actually it has been fixed for the PBES2 case in 2.2 and 2.4. PBES2 is used with AES128 and AES256. I doubt that there is any value in adding such support for the legacy RC2 and 3DES methods.

However, when we _create_ a pkcs#12 object we use 3des and thus the password length is limited! This should be fixed.

Turning this into a feature request: We should create P12 files using AES instead of 3DES

I don't see a value to do this for 2.2 and introduce a regression with that.