Am Montag, den 08.10.2012, 13:09 -0700 schrieb Phil Pennock: > On 2012-10-08 at 21:32 +0200, Kristian Fiskerstrand wrote: > > The certificate presented by keys2.kfwebs.net should be chained > > certificate containing both the CA itself and the individual cert for > > keys2.kfwebs.net. I'm not entirely sure that this is fully required, but > > at least it works for me :) > > Right, that tests subjectAltName operation in TLS certificate > verification. That works. > > Unless everyone else _replaces_ their certs with certs issued by you, > that in itself doesn't help: it means you become the only person who can > issue certs for any SKS keyserver's HTTPS interface. > > The key is for other people to be able to issue _different_ certs based > on the serverNameIndication in the TLS client hello message; vhosting, > like the Host: header in HTTP, but moved up into the TLS handshake so > that the server can select the correct key/cert pair to use for the > session. > > I'll go ahead and send you a CSR shortly, so that sks.spodhuis.org can > have two certs and we can test. :)
Hi guys, sorry for asking dumb questions, but this is something far beyond my daily business ;) I recently created a key /csr for keyserver.secretresearchfacility.com . It's signed by a CA, so I currently do have a valid crt. As I read your posts, I guess I should create a new csr for that key like: subjectAltName = @alt_names [alt_names] DNS.1 = keyserver.secretresearchfacility.com DNS.2 = hkps.pool.sks-keyservers.net and glue the results (my key, the two crt's and the intermediate(s)) together? I don't believe this will work ;) Another approach could be SNI, couldn't it? I already use namebased vhosts (thank's for your explanation of TLS, phil), so I could configure two proxies which are identical despite the hostname and the certificates. That way, I would use two different keys / crts without the need for subjectAltName.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Sks-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/sks-devel
