Hi, this already solved my mystery. Sorry that this was an easy one and thanks for all your answers! I changed the certificate and feel a bit more knowledged now. I usually retrieve TLS certificates with the attached script (feedback appreciated) on first contact, thus I falsely ignored the pool cert.
14 Jul 2013 12:08:27 +0200 Pete Stephenson <[email protected]>: > On Sun, Jul 14, 2013 at 9:46 AM, kardan <[email protected]> wrote: > Did you follow the referral and query whois.publicdomainregistry.com > to get the more detailed information about the domain? For example, > http://smartwhois.com/whois/SKS-KEYSERVERS.NET will follow the Amazing, the first time I saw somebody registering with a fingerprint in the domain holder field. > > Searching for the owner via gpg brings different results without > > success. I assume the pool is not that well mantained? Sorry, I was too tired. > I searched for the registrant of sks-keyservers.net on the keyservers > and found two current, valid public keys for them: a 4096-bit RSA key > signed by lots of people (0x6B0B9508) and a 15,360-bit(!) RSA key with > only a self-sig (0x43E67CF7). I wonder how long the 15kb key will be safe. For my understanding with current hardware it is possible to attack keys below 1kb. This means anything encrypted below in the last years will be readable quite soon. So the key used for encryption now should be choosen to not only withstand current cluster power but must last next 50 years for example. Otherwise all the data currently sniffed by the NSA, Iran, google, etc. will be plain until governments become repressive enough which is, looking at the last decade, before I am 60. (I hope you correct me to be wrong for missing a significant detail.) > The PEM certificate you mentioned, > > > SSL certificate for hkps.pool.sks-keyservers.net: > > > > -----BEGIN CERTIFICATE----- > > MIIGkzCCBXugAwIBAgIDCsjWMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJ > [snip] > > Appears to have been issued by StartSSL, a well-known CA, and has not > been signed by the pool CA. The key is issued with a > CN=www.secretresearchfacility.com. There is a pool key server running > under that domain, keyserver.secretresearchfacility.com, but it's > running on a server that uses SNI to use multiple SSL certificates on > a single server. Good to know how to overcome IPv4 scarcity for TLS. https://en.wikipedia.org/wiki/Server_Name_Indication > GnuPG appears to support SNI and so works correctly (gpg2 --search > --keyserver hkps://keyserver.secretresearchfacility.com > --keyserver-options ca-cert-file=./sks-keyservers.netCA.pem 0xDA122186 > works properly) but does curl? If not, curl would not specify the > correct hostname it's looking for and the server (which doesn't know > what hostname the client wants) would present its default CA, which is > the StartSSL-issued one. Curl has no problems with this one either. * Curl_addHandleToPipeline: length: 1 * - Conn 0 (0x8dc66a0) send_pipe: 1, recv_pipe: 0 * Connected to keyserver.secretresearchfacility.com (80.241.60.3) port 443 (#0) * found 1 certificates in /home/kardan/config/certs/sks-keyservers.netCA.pem * server certificate verification OK * common name: keyserver.secretresearchfacility.com (matched) 14 Jul 2013 13:37:18 +0200 Kristian Fiskerstrand <[email protected]>: > Also note that there is no requirement or any of the servers to offer > a human-readable web interface, and as such no checking is performed > as to how a possible such page is formed. This is a probably reason > for you reporting getting data back on a non-encrypted channel, if.e.g > you are met with a hard-coded <form action> on such a HTML template. > The pool is configured to work with direct client HKP[2] requests and > I'm not aware of any issues with this. I see, the links on https://sks-keyservers.net/i/ are indeed to http <form action="http://pool.sks-keyservers.net:11371/pks/lookup"; method="get"> -- Kardan <[email protected]> Encrypt your email: http://gnupg.org/documentation Public GPG key 9D6108AE58C06558 at hkp://pool.sks-keyservers.net fpr: F72F C4D9 6A52 16A1 E7C9 AE94 9D61 08AE 58C0 6558
sslcert-get
Description: Binary data
signature.asc
Description: PGP signature
_______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
