Thanks, what should I look out for? I don't think I can provide the .p12 directly because it is from a production provider that I do not have full access. I can provide the log and x509 public certificate again using the firefox generated one.

Recent Mozilla again changed some things. Please see T6752. Can you please provide a sample in case this is not the same problem as in T6752?

115.3.1esr

Yes, there is clearly a problem with the handling of NDEF. I have a fix for that but there are other oddities in that pkcs12 object. Do you have the Firefox version you used to create this?

That has been done modulo the bug which existed for both versions, I fixed today (T6536)

Okay, I found and fixed the import problem in 2.4 and will backport this to 2.2

Tested on the command line with

• a previously valid certificate after setting its root certificate to untrusted
• a expired certificate without the root certificate in the certificate list

With Gpg4win-4.2.1-beta31 I can no longer import the secret part of the edward.tester@demo.gnupg.com.p12 Testkey. Error is "Invalid object".

With VS-Desktop-3.2.0.0-beta214 and Gpg4win-4.2.1-beta31 the error is "Bad Passphrase" in this case.
I do not see a reason why this ticket is still open.
The already resolved Kleopatra Task T5713 is probably a duplicate of this one.

pkcs12 import should be backported, too

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

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

Needs to be checked again with stable. No backport to 2..2, though.

Currently, Kleopatra cannot do anything about this. get_passphrase in protect-tool.c asks those questions and doesn't support a way to give the user more context (e.g. by providing the file name). Once gpg-agent allows giving context, Kleopatra can add for example the file name to the data to import.

yes, one down, two to go...

I am raising this up from the wishlist. Error messages from CRL errors can be so obscure, like we just had in a support call.

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.

Same for the backport to 2.2 which uses the same test suite.

This has long been implemented due to the backport of the P12 parser and the recent rewrite of it.

This was tested by me against the actual sample and the sample is now part of our internal regression test suite.

Partly done for 2.4. The cram-octet-string stuff is missing, though.

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

Use Kleopatra which constructs the DN for you ;-).

I had a brief look at this. I don't think there's a way currently to convey "CRL Error" via a keylist result to gpgme. The --with-colons format would probably need to be extended.

I am closing this as a duplicate of T6117 even though it is not really a duplicate. But for me it does not make sense to keep this as a different issue because simplifying the dialog is directly related to making it more accessible.

I guess this is fixed with this commit for 2.2. and 2.4. Given that the report is quite old with not new infos since 2019, I'll close it.

Putting up for grabs and removing Kleopatra tag since for Kleopatra users this has been fixed (unless they manage to trigger multiple separate concurrent imports in Kleopatra).

Hello Andre Heinecke,

Hello Andre Heinecke,

Thanks for the certificate, looks good as far as I can tell. I have trouble with CRL checks for your certificate as https://crl.sectigo.com/ does not work for me. But that should not be an issue when decrypting.

Hello Andre Heinecke,

@ikloecker You are right, I only thought of public key import. Then lets serialize this. Might even make for a nicer Progressbar if we count the outstanding files.

In T4505#166463, @aheinecke wrote:

I have an Idea. Can't we read all data into memory in Kleopatra (for Certificates this should be ok) and then give this to GPGME as a single data object. So that only one process imports multiple files?

In T4505#166390, @ikloecker wrote:

I really don't want to bypass gpgme and then parse the import results and all other status output of gpgsm ourselves. I'll go for Andre's suggestion and serialize imports of multiple files.

Please attach the certificate so that we can check what is problematic with that certificate. I am changing this issue to wishlist as the solution here will most likely be that we have to extend the S/MIME capabilities of Gpg4win.

I really don't want to bypass gpgme and then parse the import results and all other status output of gpgsm ourselves. I'll go for Andre's suggestion and serialize imports of multiple files.

I meant bypass the gpgme engine and call gpgsm directly. Maybe using gpgme's spawn engine. But I am not sure whether this is really a good idea. If we can find a way to pass multiple filenames to gpgsm --server that would be better. But requires updates to gpgsm.

@werner Do I understand correctly that by "It might be easier to bypass the gpgsm and run gpgsm directly" you mean using gpgsm in server mode? Or what do you mean with "bypass gpgsm and run gpgsm" (which seems contradictory).

With 100 concurrently running gpgsm processes they all try to get the lock for the keyring. And they need to do this several times and often also for the same certificate (fetched from an external resource to complete the chain). Not good. It might be easier to bypass the gpgsm and run gpgsm directly instead of adding a feature to gpgsm to directly import from many files.

Sure, we could do this. Shouldn't make the ImportCertificatesCommand much more complex than it already is.

Reopening this as there still seem to be ways to run into a deadlock as was reported in RT#13361. While I still think this points to some issue in gpgsm, when Testing this I found the behavior of Kleopatra to be wrong.

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

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:

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.

I guess we can close this one.

If you enter a wrong password in a window, the error message will only be given after you have answered all requests for the transport passwords.

Shall we really backport this to 2.2 given that ECC for S/MIME is in most cases a smartcard thing?