I forgot: Instead of importing the missing internal CA, this works:

I agree, the question is which CRL is checked when how. Maybe there is some mistake on my side. Here is a recipe for Debian:

I don't think this is a bug. Failure to encrypt when CRL check fails is expected.

Ouch indeed. Looks like you run into a "hanging" gpg-agent situation in that case our main background process is blocked and all other processes wait for it to respond and nothing works anymore.
This should never happen and we need to fix it. But so far we have not found a way to reproduce it.

Looking at other threads I found the problem in some .lock file in my gnupg directory. One of them was locked by a running process and I was not able to delete. So I opened up task manager and I had dozens of gnupg related processes running. I killed all of them and removed any .lock file.
This way Kleopatra started again but the certificate above (aruba) was not present in the imported ones. And, of course, I'm not going to import it anymore, will use my sixt sense to trust certificates...

The exact file that created the lock is attached

The only action I can do is quit the program telling it to stop the background actvity, but I cannot use it anymore...

Ouch, worse problem here. After closing kleopatra telling it to stop doing whatever it was, I restarted the application and now it's stuck in "Loading certificate cache"

The certificate was defintely missing the tag lines, thanks. I also tried opening the certificate from that page (Windows has no problems without the tag lines) and exporting it explicitly as base64, and the output file is fine.
The problem is that the import now seems to go well, but no certificate is imported at all. I tried several times and the import box just closes after selecting the file.
I tried to close Kleopatra and it says there are ongoing background operations. At least 15 mins passed between the import and the closing tentative.
Actually, it is stuck doing something.

Thanks for the report.

Btw. I only noticed this now as I always had "disable-tor" in my config but recently removed it for testing.

We also need to fix for encryption and signature in CSR.

Thanks for that summary.

Since it seems there is a renewed interest in adding ECC support to GpgSM (as indicated by the T4098 feature request), I would like to write down here more details about this task.

See also T4013 which is about ed25519 key support

werner,
I'm the spanish user. Are you also setting default ocsp responder option?
Setting only ocsp_signer doesn't worked, there are several CA's with diferent ocsp responders.

The reporter said that it did not work for him.

A list of SHA-1 fingerprints for the valid certificates. With our without colons.

@werner what should the contents of the file look like?

I had to look it up in the code and man page too ;-)

Good to know. I thought that ocsp-signer was only used if ocsp-responder is explitly set. I've suggested the workaround in the Message Board.

Is using

In Wald someone reports that this also appears to happen when decrypting. https://wald.intevation.org/forum/message.php?msg_id=6377 Probably run-threaded will help to flush this out.

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

Gpg4win-3.1.3 was released.