On 10/05/2012 06:23 PM, Phil Pennock wrote:
Speaking for myself, I only use TLSv1+ and my nginx is built with SNI
support, so if you want to figure out a policy for handing out certs, I
can add a new cert for SNI hostnames in *.pool.sks-keyservers.net.
alternately (or in addition?), we could
On 10/06/2012 12:23 AM, Phil Pennock wrote:
I get results from:
dig -t a hkps.pool.sks-keyservers.net
dig -t srv _pgpkey-https._tcp.hkps.pool.sks-keyservers.net
but not from:
dig -t hkps.pool.sks-keyservers.net
(NOERROR, with AUTHORITY section, so just looks as though there are
Hi,
In relation to setting up a HKPS pool for sks-keyservers.net[0] I've
encountered a scenario where some input would be appreciated.
In the process of trying to figure out a mechanism to not have to
disable certificate checking when using the pool (I quite like DKG's
approach in [1]) I set up
On 2012-10-06 at 11:12 +0200, Stephan Seitz wrote:
I'ld like to add ssl to my server, but prior I'm afraid I need a few
questions answered.
If I'm going to install a self-signed *.pool.sks-keyservers.net, that
CRT wouldn't have any reputation. As long as there's no additional trust
added
On 2012-10-06 at 22:20 -0400, Phil Pennock wrote:
So, there's a `port` and an `opt-port`; the SRV lookups set `opt-port`
but not `port`, while the URL given to curl uses `port`.
It seems like changing 537 to:
port = opt-port = newport
should fix it as a stop-gap.
bugs.g10code.com is
