Re: GnuPG 2.2.4 on Windows - problems accessing some HKPS keyservers

2018-01-24 Thread David Gray via Gnupg-users
Thanks, Phil - 

I appreciate your help and your response.

Thanks,

Dave

Sent from my iPhone

> On Jan 23, 2018, at 9:51 PM, Phil Pennock  wrote:
> 
> Looks to me like a GnuPG bug.  In fact, it looks very much like
> https://dev.gnupg.org/T1447 which has been marked resolved.
> 
> The hostname there is a CNAME to Amazon DNS, and my dirmngr logfile
> records:
> 
> 2018-01-23 21:28:10 dirmngr[70787.6] TLS verification of peer failed: 
> hostname does not match
> 2018-01-23 21:28:10 dirmngr[70787.6] DBG: expected hostname: 
> keyserver-prod.v3jierkpjv.eu-west-1.elasticbeanstalk.com
> 
> The untrusted name retrieved from DNS resolution of the CNAME record is
> being used as the name for validation.
> 
> The patches to address the issue seem to focus on SRV records, so
> repaired one way in which the problem manifested, but either didn't fix
> the underlying issue, or there's been a regression.
> 
> I've opened a new ticket for the maintainers to track this.
> https://dev.gnupg.org/T3755
> 
> -Phil


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


GnuPG 2.2.4 on Windows - problems accessing some HKPS keyservers

2018-01-23 Thread David Gray via Gnupg-users
Good Evening -

 

I'm running GnuPG 2.2.4 on Windows.  I'm able to successfully query the SKS
keyserver pool via HKPS (hkps://hkps.pool.sks-keyservers.net) with no
problems.  I'm trying to query the hkps://keys.mailvelope.com keyserver, and
I'm not having any luck.  I suspect I don't have the appropriate hkp-cacert
referenced in the dirmngr, but I got the certificate by browsing to
https://keys.mailserver.com, exporting the root cert in the certification
path as a Base-64 encoded X.509 file (with .pem extension) and copying it to
my gnupg home directory, and the hkp-cacert line in dirmngr.conf references
that .PEM file.  The cert thumbprint shows:
ad7e1c28b064ef8f6003402014c3d0e3370eb58a in windows certmgr, and the full
contents of that .pem file appear at the bottom of this message for
reference.

 

I'm hoping someone may be able to point me in the right direction to
troubleshoot this a bit further - I suspect I've done something wrong but
I'm not sure how to identify exactly what it is.

 

Details below - Thanks!

 

Dave

 

This is what I get when I attempt to lookup the key for patr...@enigmail.com
  at hkps://keys.mailvelope.com:

 

C:\Users\dave>gpg --debug-all -vvv --search-keys patr...@enigmail.com

gpg: reading options from 'C:/Users/dave/AppData/Roaming/gnupg/gpg.conf'

gpg: using character set 'CP437'

gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache
memstat trust hashing ipc clock lookup extprog

gpg: DBG: [not enabled in the source] start

gpg: DBG: chan_0x0180 <- # Home: C:/Users/dave/AppData/Roaming/gnupg

gpg: DBG: chan_0x0180 <- # Config:
C:/Users/dave/AppData/Roaming/gnupg/dirmngr.conf

gpg: DBG: chan_0x0180 <- OK Dirmngr 2.2.4 at your service

gpg: DBG: connection to the dirmngr established

gpg: DBG: chan_0x0180 -> GETINFO version

gpg: DBG: chan_0x0180 <- D 2.2.4

gpg: DBG: chan_0x0180 <- OK

gpg: DBG: chan_0x0180 -> KEYSERVER --clear hkps://keys.mailvelope.com/

gpg: DBG: chan_0x0180 <- OK

gpg: DBG: chan_0x0180 -> KS_SEARCH -- patr...@enigmail.com

gpg: DBG: chan_0x0180 <- ERR 285212985 Wrong name 

gpg: error searching keyserver: Wrong name

gpg: keyserver search failed: Wrong name

gpg: DBG: chan_0x0180 -> BYE

gpg: DBG: [not enabled in the source] stop

gpg: keydb: handles=0 locks=0 parse=0 get=0

gpg:build=0 update=0 insert=0 delete=0

gpg:reset=0 found=0 not=0 cache=0 not=0

gpg: kid_not_found_cache: count=0 peak=0 flushes=0

gpg: sig_cache: total=0 cached=0 good=0 bad=0

gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0

  outmix=0 getlvl1=0/0 getlvl2=0/0

gpg: rndjent stat: collector=0x calls=0 bytes=0

gpg: secmem usage: 0/32768 bytes in 0 blocks

 

The corresponding logs from dirmngr show:

 

2018-01-22 19:40:43 dirmngr[1664] handler for fd 864 started

2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x0360 -> # Home:
C:/Users/dave/AppData/Roaming/gnupg

2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x0360 -> # Config:
C:/Users/dave/AppData/Roaming/gnupg/dirmngr.conf

2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x0360 -> OK Dirmngr 2.2.4
at your service

2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x0360 <- GETINFO version

2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x0360 -> D 2.2.4

2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x0360 -> OK

2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x0360 <- KEYSERVER --clear
hkps://keys.mailvelope.com/

2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x0360 -> OK

2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x0360 <- KS_SEARCH --
patr...@enigmail.com

2018-01-22 19:40:43 dirmngr[1664] TLS handshake failed: Wrong name 

2018-01-22 19:40:43 dirmngr[1664] error connecting to
'https://52.50.100.145:443': Wrong name

2018-01-22 19:40:43 dirmngr[1664] command 'KS_SEARCH' failed: Wrong name


2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x0360 -> ERR 285212985
Wrong name 

2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x0360 <- BYE

2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x0360 -> OK closing
connection

2018-01-22 19:40:43 dirmngr[1664] handler for fd 864 terminated

 

 

By contrast, this is what I get when I query the SKS pool for the same key
via HKPS:

 

C:\Users\dave>gpg --debug-all -vvv --keyserver
hkps://hkps.pool.sks-keyservers.net --search-keys patr...@enigmail.com

gpg: reading options from 'C:/Users/dave/AppData/Roaming/gnupg/gpg.conf'

gpg: using character set 'CP437'

gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache
memstat trust hashing ipc clock lookup extprog

gpg: DBG: [not enabled in the source] start

gpg: DBG: chan_0x0190 <- # Home: C:/Users/dave/AppData/Roaming/gnupg

gpg: DBG: chan_0x0190 <- # Config:
C:/Users/dave/AppData/Roaming/gnupg/dirmngr.conf

gpg: DBG: chan_0x0190 <- OK Dirmngr 2.2.4 at your service

gpg: DBG: connection to the dirmngr established

gpg: DBG: chan_0x0190 -> GETINFO version