gpg2 --refresh-keys 一般错误

Question

不幸的是我在运行时遇到以下错误

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

正如你可以从上面的收集，我已经配置了密钥服务器是hkps://keys.openpgp.org在~/.gnupg/dirmngr.conf所建议的在这里。这是完整的内容~/.gnupg/dirmngr.conf：

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

gpg2 --refresh-keys在pkill dirmngr给出这个之后再次运行/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 'https://keys.openpgp.org:443': 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. 

这里有什么问题？

• 我是否必须指定 (TLS) 证书 gpg2单独？如果是，我该怎么做？
• 或者我错过了什么~./gnupg/dirmngr.conf？
• 或者为什么 TLS 连接失败？

在此先感谢您的帮助！

编辑 1

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

编辑 2

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

在更彻底地阅读日志并检查手册dirmngr页后，我意识到在我的系统上整个/etc/gnupg目录都丢失了。

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’.

由于这可能具有相关性，我如何创建并填充/etc/gnupg其默认值？还是我必须手动完成？为什么首先缺少这个目录？

Answer 1

或者我在 ~./gnupg/dirmngr.conf 中遗漏了一些东西？

对我来说以下修复了它：

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

该文档表示，如果hkp-cacert未指定，它将使用常规主机名的系统证书存储和默认密钥服务器池的捆绑证书。

$ 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: https://hkps.pool.sks-keyservers.net:443
(1)     Kristian Fiskerstrand <kf@gnupg.net>
        Kristian Fiskerstrand <k_f@gentoo.org>
        Kristian Fiskerstrand <kf@sumptuouscapital.com>
        Kristian Fiskerstrand <kristian.fiskerstrand@sumptuouscapital.com>
          4096 bit RSA key 0B7F8B60E3EDFAE3, created: 2007-12-15, expires: 2020-12-31
...

$ gpg --version
gpg (GnuPG) 2.2.21

在 3 台机器上遇到这个问题，并在 2 台机器（Ubuntu Docker 和 Arch Linux）上修复了它，第三台 Arch 机器从未与 hkps 一起工作，仅与 hkp 一起工作。尽管有相同版本的 gnupg，但在~/gnupg.conf、 和同一网络上没有奇怪的配置。

似乎仅仅指定keyserver pgp.mit.eduingnupg.conf也可以通过下降到 hkp 协议来修复它

池概述：https://sks-keyservers.net/overview-of-pools.php