If using SRV records for a hostname, GnuPG 2.1.19 is now trying to use _pgpkey-http and _pgpkey-https as SRV lookups, which is great.
The result is cached as part of the record for the hostname.
So if you use hkp://foo _and then_ hkps://foo then the SRV result for _pgpkey-http is used for hkps: instead of picking up the _pgpkey-https result. These should normally be expected to be different ports, rather than sharing.
Not currently diving into the DNS/dirmngr internals to tackle this, hoping this, and the appropriate test resources below, are enough to help?
Below:
- commands to reproduce
- dirmngr log (debug 1024)
- details of the setup
The setup is dual-cert RSA and ECC for keyserver.spodhuis.org as part of my testing how well this might work with clients.
Reproducing
% gpg --keyserver hkp://keyserver.spodhuis.org --refresh-key 0x4D1E900E14C1CC04 [success] % gpg --keyserver hkps://keyserver.spodhuis.org --refresh-key 0x4D1E900E14C1CC04 gpg: refreshing 1 key from hkps://keyserver.spodhuis.org gpg: keyserver refresh failed: No keyserver available % gpgconf --kill dirmngr % gpg --keyserver hkps://keyserver.spodhuis.org --refresh-key 0x4D1E900E14C1CC04 [success]
Logs
2017-03-31 16:25:49 dirmngr[22935.6] DBG: chan_6 -> S KEYSERVER hkp://keyserver.spodhuis.org 2017-03-31 16:25:49 dirmngr[22935.6] DBG: chan_6 -> OK 2017-03-31 16:25:49 dirmngr[22935.6] DBG: chan_6 <- KS_GET -- 0xACBB4324393ADE3515DA2DDA4D1E900E14C1CC04 2017-03-31 16:25:49 dirmngr[22935.6] resolve_dns_addr for 'keyserver.spodhuis.org': 'keyserver.spodhuis.org' [already known] 2017-03-31 16:25:49 dirmngr[22935.6] resolve_dns_addr for 'keyserver.spodhuis.org': 'keyserver.spodhuis.org' [already known] 2017-03-31 16:25:49 dirmngr[22935.6] resolve_dns_addr for 'keyserver.spodhuis.org': 'keyserver.spodhuis.org' [already known] 2017-03-31 16:25:49 dirmngr[22935.6] DBG: chan_6 -> S SOURCE http://keyserver.spodhuis.org:11374 2017-03-31 16:25:49 dirmngr[22935.6] DBG: (104202 bytes sent via D lines not shown) 2017-03-31 16:25:49 dirmngr[22935.6] DBG: chan_6 -> OK 2017-03-31 16:25:49 dirmngr[22935.6] DBG: chan_6 <- BYE 2017-03-31 16:25:53 dirmngr[22935.6] DBG: chan_6 <- KEYSERVER --clear hkps://keyserver.spodhuis.org 2017-03-31 16:25:53 dirmngr[22935.6] DBG: chan_6 -> OK 2017-03-31 16:25:53 dirmngr[22935.6] DBG: chan_6 <- KEYSERVER 2017-03-31 16:25:53 dirmngr[22935.6] DBG: chan_6 -> S KEYSERVER hkps://keyserver.spodhuis.org 2017-03-31 16:25:53 dirmngr[22935.6] DBG: chan_6 -> OK 2017-03-31 16:25:53 dirmngr[22935.6] DBG: chan_6 <- KS_GET -- 0xACBB4324393ADE3515DA2DDA4D1E900E14C1CC04 2017-03-31 16:25:54 dirmngr[22935.6] TLS handshake failed: An unexpected TLS packet was received. 2017-03-31 16:25:54 dirmngr[22935.6] error connecting to 'https://keyserver.spodhuis.org:11374': Network error 2017-03-31 16:25:54 dirmngr[22935.6] marking host 'keyserver.spodhuis.org' as dead 2017-03-31 16:25:54 dirmngr[22935.6] host 'keyserver.spodhuis.org' marked as dead 2017-03-31 16:25:54 dirmngr[22935.6] command 'KS_GET' failed: No keyserver available 2017-03-31 16:25:54 dirmngr[22935.6] DBG: chan_6 -> ERR 167772346 No keyserver available <Dirmngr> 2017-03-31 16:25:54 dirmngr[22935.6] DBG: chan_6 <- BYE 2017-03-31 16:26:13 dirmngr[22935.6] DBG: chan_6 <- KILLDIRMNGR 2017-03-31 16:26:16 dirmngr[22948.6] DBG: chan_6 <- KEYSERVER --clear hkps://keyserver.spodhuis.org 2017-03-31 16:26:16 dirmngr[22948.6] DBG: chan_6 -> OK 2017-03-31 16:26:16 dirmngr[22948.6] DBG: chan_6 <- KEYSERVER 2017-03-31 16:26:16 dirmngr[22948.6] DBG: chan_6 -> S KEYSERVER hkps://keyserver.spodhuis.org 2017-03-31 16:26:16 dirmngr[22948.6] DBG: chan_6 -> OK 2017-03-31 16:26:16 dirmngr[22948.6] DBG: chan_6 <- KS_GET -- 0xACBB4324393ADE3515DA2DDA4D1E900E14C1CC04 2017-03-31 16:26:16 dirmngr[22948.6] resolve_dns_addr for 'keyserver.spodhuis.org': 'keyserver.spodhuis.org' [already known] 2017-03-31 16:26:16 dirmngr[22948.6] resolve_dns_addr for 'keyserver.spodhuis.org': 'keyserver.spodhuis.org' [already known] 2017-03-31 16:26:16 dirmngr[22948.6] resolve_dns_addr for 'keyserver.spodhuis.org': 'keyserver.spodhuis.org' [already known] 2017-03-31 16:26:17 dirmngr[22948.6] DBG: chan_6 -> S SOURCE https://keyserver.spodhuis.org:11373 2017-03-31 16:26:17 dirmngr[22948.6] DBG: (104202 bytes sent via D lines not shown) 2017-03-31 16:26:17 dirmngr[22948.6] DBG: chan_6 -> OK 2017-03-31 16:26:17 dirmngr[22948.6] DBG: chan_6 <- BYE
Setup
The hostname "keyserver.spodhuis.org" has both sets of SRV records, on non-standard ports; this hostname is an alias for "sks.spodhuis.org" (same backend SKS keyserver) but different nginx server stanzas in front of it. I set this up in Dec 2012 and "keyserver" as a hostname is primarily for testing by me.
The normal :443 port serves with SNI to select between the sks-keyservers.net CA-issued cert for pool hostnames (pool.sks-keyservers.net *.pool.sks-keyservers.net) and a Let's Encrypt cert for "sks.spodhuis.org" itself. For "keyserver.spodhuis.org", the HTTPS cert still uses my own private CA. This is on the normal :443 port and
also :11373; meanwhile :11374 is non-TLS. These were done for testing SRV for other bug-reports.
DNS:
_pgpkey-http._tcp.keyserver IN SRV 10 10 11374 keyserver _pgpkey-https._tcp.keyserver IN SRV 10 10 11373 keyserver
Today I refreshed the HTTPS certs used for "keyserver", to make them dual RSA+ECDSA. I then tried to test how this worked with GnuPG and ran smack into this problem.
The certs used for "keyserver.spodhuis.org" are issued from the two roots at:
<https://www.security.spodhuis.org/>
- "globnixCA4" is an RSA-based root issuing certs for RSA keys.
- "globnixCA5" is an ECC CA, on secp384r1, issuing certs for ECDSA keys.
I run with ~/.gnupg/dirmngr.conf specifying:
hkp-cacert /Users/pdp/.gnupg/CA/hkp-cacerts.pem
(and equiv /home for other systems) and that file containing Kristian's sks-keyservers.net root, my own roots and the Let's Encrypt roots.