Page MenuHome GnuPG
Create Task
Maniphest T7208

Default keyserver search fails (Gpg4win 4.3.1) no "Inquire" "Callback" set for IPC though keyserver is availab.e
Closed, ResolvedPublic
Actions

Description

Tested on Gpg4win 4.3.1 which includes

GnuPG 2.4.5
Kleopatra 3.2.2

On Windows 10 German

gpg --keyserver hkps://keyserver.ubuntu.com --search-keys bernhard@intevation.de
gpg: error searching keyserver: Kein "Inquire" "Callback" für IPC gesetzt
gpg: Suche auf dem Schlüsselserver fehlgeschlagen: Kein "Inquire" "Callback" für IPC gesetzt

and this is the default, directly after a fresh install:

gpgconf --list-options dirmngr
[..]
keyserver:16:0:Benutze Schlüsselserver unter der URL:1:1::"hkps%3a//keyserver.ubuntu.com::

the keyserver search does work, though when leaving out the prefix, e.g.

>gpg --keyserver keyserver.ubuntu.com --search-keys bernhard@intevation.de
gpg: data source: http://185.125.188.27:11371
(1)     Bernhard Reiter <bernhard@intevation.de>
[..]

This affects the Kleopatra search as well and the configuration.: When trying to configure "keyserver.ubuntut.com" or "pubkeys.intevation.de" it will add the "hkps://" and it does not work anymore.

Event Timeline

bernhard created this task.Jul 19 2024, 5:26 PM
bernhard updated the task description. (Show Details)
• aheinecke added a subscriber: • aheinecke.Jul 30 2024, 8:18 PM

Hi Bernhard,

I can't reproduce that. Here is my test:

Is it possible that this is again a problem related to a test VM not updated so that it might not have up to date certificates? Since only https fails for you. Maybe you can browse to https://keyserver.ubuntu.com with edge to see if that either triggers the update of a required cert or indicates an error.

bernhard added a comment.EditedJul 31 2024, 9:48 AM

Since only https fails for you.

You are right, when using http:// or hkp:// as prefixes explicitly it works.

(It would be a different issue, but shouldn't GnuPG add a TLS variant by default if no prefix is given? For privacy reasons?)

I've browsed https://keyserver.ubuntu.com/ and https://pubkeys.intevation.de with edge and I cannot see a problem.

You guess right that the test was done in a VM, however this one is used an updated for other things as well. I'll run another update and see and next I'll turn up dirmngr's logging to see more details.

Thank you for trying to reproduce my problem, sorry for having missed the non-TLS variant.

bernhard added a comment.EditedJul 31 2024, 10:39 AM

next I'll turn up dirmngr's logging

You guess was correct, the TLS library does not like the certificate. Here are parts of the log (in German):

dirmngr[3008]: DBG: Using TLS library: NTBTLS 0.3.2
dirmngr[3008]: DBG: http.c:connect_server: trying name='185.125.188.26' port=443
dirmngr[3008]: DBG: http.c:2893:socket_new: object 0x02a6a1a8 for fd 964 created
dirmngr[3008]: Zertifikat wurde zwischengespeichert
dirmngr[3008]: DBG: BEGIN Certificate 'subject':
dirmngr[3008]: DBG:      serial: 045E4DACC54C409C76EE6DBD5C0BEDD9E2DA
dirmngr[3008]: DBG:   notBefore: 2024-05-31 18:57:02
dirmngr[3008]: DBG:    notAfter: 2024-08-29 18:57:01
dirmngr[3008]: DBG:      issuer: CN=R3,O=Let's Encrypt,C=US
dirmngr[3008]: DBG:     subject: CN=hockeypuck.ubuntu.com
dirmngr[3008]: DBG:         aka: (8:dns-name21:hockeypuck.ubuntu.com)
dirmngr[3008]: DBG:         aka: (8:dns-name24:keyserver-new.ubuntu.com)
dirmngr[3008]: DBG:         aka: (8:dns-name20:keyserver.ubuntu.com)
dirmngr[3008]: DBG:   hash algo: 1.2.840.113549.1.1.11
dirmngr[3008]: DBG:   SHA1 fingerprint: 4143DD46AF46293467635C1CE75DA1082DC22FBC
dirmngr[3008]: DBG: END Certificate
dirmngr[3008]: Hinweis: Die unkritische Zertifikatsrichtlinie ist nicht erlaubt
dirmngr[3008]: DBG: find_cert_bysubject: certificate found in the cache by subject DN
dirmngr[3008]: DBG: got issuer's certificate:
dirmngr[3008]: DBG: BEGIN Certificate 'issuer':
dirmngr[3008]: DBG:      serial: 00912B084ACF0C18A753F6D62E25A75F5A
dirmngr[3008]: DBG:   notBefore: 2020-09-04 00:00:00
dirmngr[3008]: DBG:    notAfter: 2025-09-15 16:00:00
dirmngr[3008]: DBG:      issuer: CN=ISRG Root X1,O=Internet Security Research Group,C=US
dirmngr[3008]: DBG:     subject: CN=R3,O=Let's Encrypt,C=US
dirmngr[3008]: DBG:   hash algo: 1.2.840.113549.1.1.11
dirmngr[3008]: DBG:   SHA1 fingerprint: A053375BFE84E8B748782C7CEE15827A6AF5A405
dirmngr[3008]: DBG: END Certificate
[..]
dirmngr[3008]: DBG: rsa_verify    => Good
dirmngr[3008]: DBG: check_cert_sig: gcry_pk_verify: Erfolg
dirmngr[3008]: Das Zertifikat ist korrekt
dirmngr[3008]: Hinweis: Die unkritische Zertifikatsrichtlinie ist nicht erlaubt
dirmngr[3008]: DBG: find_cert_bysubject: certificate not in cache
dirmngr[3008]: DBG: chan_0x000003c8 -> INQUIRE SENDCERT_SKI 79B459E67BB6E5E40173800888C81A58F6E99B6E /CN=ISRG Root X1,O=Internet Security Research Group,C=US
dirmngr[3008]: DBG: chan_0x000003c8 <- END
dirmngr[3008]: DBG: find_cert_bysubject: certificate not returned by caller - doing lookup
dirmngr[3008]: Fehler beim Holen des Zertifikats mittels Subject: Konfigurationsfehler
dirmngr[3008]: issuer certificate {79B459E67BB6E5E40173800888C81A58F6E99B6E} not found using authorityKeyIdentifier
dirmngr[3008]: Herausgeberzertifikat nicht gefunden
dirmngr[3008]: issuer certificate: #/CN=ISRG Root X1,O=Internet Security Research Group,C=US
dirmngr[3008]: TLS handshake failed: Fehlendes Herausgeberzertifikat in der Kette <Dirmngr>
dirmngr[3008]: Fehler beim Verbinden mit 'https://185.125.188.26:443': Fehlendes Herausgeberzertifikat in der Kette
dirmngr[3008]: command 'KS_SEARCH' failed: Fehlendes Herausgeberzertifikat in der Kette
dirmngr[3008]: DBG: chan_0x000003c8 -> ERR 167772345 Fehlendes Herausgeberzertifikat in der Kette <Dirmngr>

There are a number of system certificates which aren't loading, however I have yet to find out which one precisely. Messages read like

2024-07-31 10:19:01 dirmngr[6504] Fehler beim Laden des Zertifikats `ROOT': Zertifikat abgelaufen
2024-07-31 10:19:01 dirmngr[6504] Fehler beim Laden des Zertifikats `CA': Zertifikat abgelaufen

So 27 ROOT are loaded and 3 aren't.
Interesting enough powershell

dir Cert:\LocalMachine\Root
dir Cert:\LocalMachine\CA

does not list ISRG and certmngr also cannot find it. If you use edge to check into the certificate path, there is it, valid.

bernhard closed this task as Resolved.Jul 31 2024, 11:24 AM
bernhard claimed this task.

I've checked the windows configuration and the automatic update of root certificates is not switched off.
Looking into the windows events view I did not see the certificate update, but after a while I did (restarts, edge attempts installation of firefox). So probably the edge view may have triggered this update, but it did not show directly in the cert store and thus not for Gnupg.

The advise to find the event came from https://community.letsencrypt.org/t/fixing-windows-installs-that-dont-receive-updates-to-their-trusted-roots/161162/29 "open the Windows event viewer, navigate to Windows Logs > Applications, and filter through 4097 ID"

bernhard added a comment.Jul 31 2024, 12:04 PM

Followup: Using edge and a restart did not trigger the installation of of CN=ISRG Root X1,O=Internet Security Research Group,C=US.

https://woshub.com/updating-trusted-root-certificates-in-windows-10/ was helpful to understand the mechanisms, and using

certutil -generateSSTFromWU c:\windows\temp\roots.sst

and opening this file (in the explorer with administration right defaulting to certmngr) and looking at the cert in there triggered the update event:

Die automatische Aktualisierung des Drittanbieterstammzertifikats wurde erfolgreich ausgeführt: Antragsteller: <CN=ISRG Root X1, O=Internet Security Research Group, C=US> Sha1-Fingerabdruck: <CABD2A79A1076A31F21D253635CB039D4329A5E8>.