gpg2 --refresh-keys general error

unfortunately I experience the following error when running

$ gpg2 --refresh-keys gpg: refreshing 18 keys from hkps://keys.openpgp.org gpg: keyserver refresh failed: General error 

As you can gather from the above, I've configured the keyserver to be hkps://keys.openpgp.org in ~/.gnupg/dirmngr.conf as suggested here. This is the full content of ~/.gnupg/dirmngr.conf:

keyserver hkps://keys.openpgp.org verbose debug 4096 debug-level 4096 debug-all log-file /tmp/dirmngr.log 

Running gpg2 --refresh-keys again after pkill dirmngr gives this in /tmp/dirmngr.log

2020-04-19 23:36:35 dirmngr[20588.0] listening on socket '/home/whoami/.gnupg/S.dirmngr' 2020-04-19 23:36:35 dirmngr[20589.0] can't access directory '/etc/gnupg2/trusted-certs': No such file or directory 2020-04-19 23:36:35 dirmngr[20589.0] can't access directory '/etc/gnupg2/extra-certs': No such file or directory 2020-04-19 23:36:35 dirmngr[20589.0] permanently loaded certificates: 0 2020-04-19 23:36:35 dirmngr[20589.0] runtime cached certificates: 0 2020-04-19 23:36:36 dirmngr[20589.0] handler for fd 0 started 2020-04-19 23:36:36 dirmngr[20589.0] DBG: chan_0 -> # Home: /home/whoami/.gnupg 2020-04-19 23:36:36 dirmngr[20589.0] DBG: chan_0 -> # Config: /home/whoami/.gnupg/dirmngr.conf 2020-04-19 23:36:36 dirmngr[20589.0] DBG: chan_0 -> OK Dirmngr 2.1.11 at your service 2020-04-19 23:36:36 dirmngr[20589.0] connection from process 20586 (1000:1000) 2020-04-19 23:36:36 dirmngr[20589.0] DBG: chan_0 <- GETINFO version 2020-04-19 23:36:36 dirmngr[20589.0] DBG: chan_0 -> D 2.1.11 2020-04-19 23:36:36 dirmngr[20589.0] DBG: chan_0 -> OK 2020-04-19 23:36:36 dirmngr[20589.0] DBG: chan_0 <- KEYSERVER 2020-04-19 23:36:36 dirmngr[20589.0] DBG: chan_0 -> S KEYSERVER hkps://keys.openpgp.org 2020-04-19 23:36:36 dirmngr[20589.0] DBG: chan_0 -> OK 2020-04-19 23:36:36 dirmngr[20589.0] DBG: chan_0 <- KS_GET -- LIST_OF_KEYS 2020-04-19 23:36:36 dirmngr[20589.0] resolve_dns_addr for 'keys.openpgp.org': 'keys.openpgp.org' [already known] 2020-04-19 23:36:36 dirmngr[20589.0] resolve_dns_addr for 'keys.openpgp.org': 'keys.openpgp.org' [already known] 2020-04-19 23:36:36 dirmngr[20589.0] TLS verification of peer failed: status=0x0042 2020-04-19 23:36:36 dirmngr[20589.0] TLS verification of peer failed: The certificate is NOT trusted. The certificate issuer is unknown. 2020-04-19 23:36:36 dirmngr[20589.0] DBG: expected hostname: keys.openpgp.org 2020-04-19 23:36:36 dirmngr[20589.0] DBG: BEGIN Certificate 'server[0]': 2020-04-19 23:36:36 dirmngr[20589.0] DBG: serial: 031419524A880F1D74B7C7BF3514F95D3FFA 2020-04-19 23:36:36 dirmngr[20589.0] DBG: notBefore: 2020-04-02 04:32:09 2020-04-19 23:36:36 dirmngr[20589.0] DBG: notAfter: 2020-07-01 04:32:09 2020-04-19 23:36:36 dirmngr[20589.0] DBG: issuer: CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US 2020-04-19 23:36:36 dirmngr[20589.0] DBG: subject: CN=keys.openpgp.org 2020-04-19 23:36:36 dirmngr[20589.0] DBG: hash algo: 1.2.840.113549.1.1.11 2020-04-19 23:36:36 dirmngr[20589.0] DBG: SHA1 fingerprint: 447582CA4F0DDA406F88D52DBBDF35B16C060B7D 2020-04-19 23:36:36 dirmngr[20589.0] DBG: END Certificate 2020-04-19 23:36:36 dirmngr[20589.0] DBG: BEGIN Certificate 'server[1]': 2020-04-19 23:36:36 dirmngr[20589.0] DBG: serial: 0A0141420000015385736A0B85ECA708 2020-04-19 23:36:36 dirmngr[20589.0] DBG: notBefore: 2016-03-17 16:40:46 2020-04-19 23:36:36 dirmngr[20589.0] DBG: notAfter: 2021-03-17 16:40:46 2020-04-19 23:36:36 dirmngr[20589.0] DBG: issuer: CN=DST Root CA X3,O=Digital Signature Trust Co. 2020-04-19 23:36:36 dirmngr[20589.0] DBG: subject: CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US 2020-04-19 23:36:36 dirmngr[20589.0] DBG: hash algo: 1.2.840.113549.1.1.11 2020-04-19 23:36:36 dirmngr[20589.0] DBG: SHA1 fingerprint: E6A3B45B062D509B3382282D196EFE97D5956CCB 2020-04-19 23:36:36 dirmngr[20589.0] DBG: END Certificate 2020-04-19 23:36:36 dirmngr[20589.0] TLS connection authentication failed: General error 2020-04-19 23:36:36 dirmngr[20589.0] error connecting to ' General error 2020-04-19 23:36:36 dirmngr[20589.0] TLS verification of peer failed: status=0x0042 2020-04-19 23:36:36 dirmngr[20589.0] TLS verification of peer failed: The certificate is NOT trusted. The certificate issuer is unknown. 

What's the problem here?

• Do I have to specify (TLS) certificates for gpg2 separately? If yes, how do I do so?
• Or am I missing something in ~./gnupg/dirmngr.conf?
• Or why else is the TLS connection failing?

Thanks in advance for your help!

EDIT 1

$ gpg2 --version | head -n 1 gpg (GnuPG) 2.1.11 

EDIT 2

$ dirmngr --version | head -n 1 dirmngr (GnuPG) 2.1.11 

After reading the log more thoroughly and checking the dirmngr manpage, I realized that on my system the whole /etc/gnupg directory is missing.

FILES Dirmngr makes use of several directories when running in daemon mode: ~/.gnupg /etc/gnupg The first is the standard home directory for all configuration files. In the deprecated system daemon mode the second direc‐ tory is used instead. /etc/gnupg/trusted-certs This directory should be filled with certificates of Root CAs you are trusting in checking the CRLs and signing OCSP Reponses. Usually these are the same certificates you use with the appli‐ cations making use of dirmngr. It is expected that each of these certificate files contain exactly one DER encoded certifi‐ cate in a file with the suffix ‘.crt’ or ‘.der’. dirmngr reads those certificates on startup and when given a SIGHUP. Certifi‐ cates which are not readable or do not make up a proper X.509 certificate are ignored; see the log file for details. Applications using dirmngr (e.g. gpgsm) can request these cer‐ tificates to complete a trust chain in the same way as with the extra-certs directory (see below). Note that for OCSP responses the certificate specified using the option --ocsp-signer is always considered valid to sign OCSP requests. /etc/gnupg/extra-certs This directory may contain extra certificates which are pre‐ loaded into the interal cache on startup. Applications using dirmngr (e.g. gpgsm) can request cached certificates to complete a trust chain. This is convenient in cases you have a couple intermediate CA certificates or certificates ususally used to sign OCSP reponses. These certificates are first tried before going out to the net to look for them. These certificates must also be DER encoded and suffixed with ‘.crt’ or ‘.der’. 

Since this might be of relevance, how can I create and fill /etc/gnupg with its default values? Or do I have to do it manually? And why is this directory missing in the first place?

1 Answer

Or am I missing something in ~./gnupg/dirmngr.conf?

For me the following fixed it:

$ echo "hkp-cacert /usr/share/gnupg/sks-keyservers.netCA.pem" >> ~/.gnupg/dirmngr.conf 

The documentation says that if hkp-cacert isn't specified it uses the system certificate store for regular hostnames and the the bundled certificate for the default keyserver pool.

$ gpg --search-keys 0B7F8B60E3EDFAE3 gpg: error searching keyserver: General error gpg: keyserver search failed: General error $ echo "hkp-cacert /usr/share/gnupg/sks-keyservers.netCA.pem" >> ~/.gnupg/dirmngr.conf $ systemctl --user stop dirmngr.service # or restart manually, this assumes socket activation $ gpg --search-keys 0B7F8B60E3EDFAE3 gpg: data source: (1) Kristian Fiskerstrand <> Kristian Fiskerstrand <> Kristian Fiskerstrand <> Kristian Fiskerstrand <> 4096 bit RSA key 0B7F8B60E3EDFAE3, created: 2007-12-15, expires: 2020-12-31 ... $ gpg --version gpg (GnuPG) 2.2.21 

Encountered this on 3 machines and it fixed it on 2 machines (Ubuntu Docker and Arch Linux) and the third Arch machine never worked with hkps, only hkp. Despite having the same version of gnupg, no strange configs in ~/gnupg.conf, and on the same network.

Seems that just specifying keyserver pgp.mit.edu in gnupg.conf also fixes it by dropping to the hkp protocol

Pool overview: