On the SSL issue: keys.gnupg.net is an alias to the SKS keyserver pool, which is a number of public volunteer run servers:
https://sks-keyservers.net/status/
My guess is you hit a misconfigured one that redirected you to TLS without checking what host you requested.
For example I redirect http://keyserver.paulfurley.com to https://keyserver.paulfurley.com *only* if the requested host is keyserver.paulfurley.com. Otherwise I would serve a certificate with a mismatching domain.
I'd recommend posting your finding to the sks-devel mailing list since it's probably something the pool should look out for and warn servers they're misconfigured. (I'll post it in the morning if you like.)
Paul
On Jul 10, 2017 at 10:58 pm, <tor (mailto:tor@anondroid.com)> wrote:
Actually, the directions on https://www.torproject.org/docs/debian.html.en work okay. I was trying to automate things with Ansible, but the format changed at some point, from something like:
apt_key: id=A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 url=http://keys.gnupg.net/pks/lookup?op=get&search=A3C4F0F979CAA22CDBA8F512E...
to:
apt_key: id=A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 keyserver=keys.gnupg.net
The URL at /pks/lookup no longer exists, so I saw a 404. Using the newer format with just the hostname of the keyserver it works okay.
Regarding http://keys.gnupg.net I still don't know why there is a SSL mismatch in the browser, or why you can no longer access the web UI, but it's not as broken as it looked.
My guess is you hit a misconfigured one that redirected you to TLS without checking what host you requested.
Makes sense. I'd assume the issue is with keyserver.uz.sns.it, based on the cert I saw for uz.sns.it. I'm not able to reproduce the problem now, but I'm on a different network.
I'd recommend posting your finding to the sks-devel mailing list ... I'll post it in the morning if you like.
Please do if you think it would be helpful. Thanks Paul.
tor-relays@lists.torproject.org