The original reporter in the gpg4win-forums reports that this does not work reliably. :-/

Gpg4win-3.1.3 was released.

We have a progress dialog now and only show details on request. I've also fixed a bug that you could trigger learning the keys twice which lead to undefined behavior.

Hi,
Can I ask if there is any update on the issue that I face?

Ok
Thanks for your answer

There is currently no ECC key support in the S/MIME component of Gpg4win. I've edited the task a bit to reflect that. So it is impossible to generate an ECC Key for S/MIME with Kleopatra.

I can't reproduce this. When I make Dirmngr offline I correctly get a No CRL known error. So it must be something different.

Tester reports that this works now.

I got feedback from the user that had the problem. It's fixed with 2.2.9 which contains your commit afaik.

This was a misunderstanding. Import is possible. The german translation of Kleopatra wrongly indicated an error because it translated "unknown certificates" as "ungültige Zertifikate".

Commit rEbd5bcd2dd19ef0b1c3d33a3a388b537ba08a4eb6

it is not due to windows but due to the use of NTBTLS. I have the same problem here... and found it: We call es_fflush to let ntbtls flush its internal buffers but libgpg-error's estream module does no propagate this explicit flush to the cookie functions of ntbtls. Thus ntbtls gets stuck most of the time. I am not sure when this regression happened but it is pretty obvious.

I have logging to a socket always enabled. That may explain why I don't see that error on Unix.

Hi Werner,
I have performed some experiments on the issue I have and the following are the results:

I was not aware that you could do this at all. You are right in that to start supporting this we first need to update libksba.

Hi Werner,
The issue is the following:
I have 2 certificates in the trusted-certificates folder that is searched by gpgsm (C:\ProgramData\Gnu\etc\gnupg\trusted-certs) which I want to trust. When dirmngr starts, it reads the Windows trusted certifcate store (certlm.msc for both system and user - I don't know the path / location of the windows certificates folder outside certlm) and builds the list of certificates to use. Once this list is read and if any duplicates are found in the trusted-certificate folder, it ignores them - they are already present.

I do not fully understand your problem. Can you please explain it with an example and also state the full file names of the mentioned folders?