Page MenuHome GnuPG

Kleopatra: No error when import from Keyserver fails
Open, NormalPublic


When searching on a keyserver using an IP and https. eg. I get search results but when I try to import certitifactes kleopatra always shows "0 imported".

The command line shows general error.

Event Timeline

aheinecke created this task.

Oh, more testing shows that this works on Linux. strange.

Turns out the error happened because on Windows I tested with the IP address and not the name. With gpg-connect-agent --dirmngr I get:

S NOTE tls_cert_error 285212985 bad cert for '': Hostname does not match the certificate
ERR 285212985 Falscher Name <TLS>

But strangely enough KS_SEARCH works without error. So this can be reproduced by:

To reproduce:

 gpg --keyserver --search
gpg: data source:
(1)     Andre Heinecke <>
        Andre Heinecke <>
        Andre Heinecke <>
        Andre Heinecke <>
        Andre Heinecke <>
        Andre Heinecke <>
        Andre Heinecke <>
          3072 bit RSA key 1FDF723CF462B6B1, created: 2015-12-08
(2)       key 55BE9C59C97822F5
(3)       1024 bit DSA key 5DE9385CC97822F5, created: 2009-11-23
(4)       771 bit ECDSA key F869996058BD45EC, created: 2014-11-18
Keys 1-4 of 4 for "".  Enter number(s), N)ext, or Q)uit > 1
gpg: error searching keyserver: General error
gpg: keyserver search failed: General error

And the error message is "eaten" by Kleopatra.

aheinecke renamed this task from Kleopatra: Import from keyserver does not work to Kleopatra: No error when import from Keyserver fails.Aug 24 2022, 12:27 PM
aheinecke lowered the priority of this task from High to Normal.
aheinecke updated the task description. (Show Details)
aheinecke edited projects, added gnupg; removed Restricted Project.

If you use an IP address there is no server name and thus a) TLS can't check the name and b) virtual servers won't work. But as you stated this is not the problem: With rGb231959728a0056 (T2924) https is handled in another way than hkps.
Now, that change was only applied to KS_GET and not to KS_SEARCH. This is kind of correct but shows this surprising behaviour: For the preferred keyserver we really want to do a plain fetch and don't have all the hkp ip/name mapping we do.

I am not sure how to fix this without breaking other usages.