[jdev] virtual hosting and certificate checking

[Jonathan Siegle]

Peter Saint-Andre said the following on 3/1/06 1:59 PM:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> JD Conley wrote:
>>> address. Naturally we'll need to clarify this in rfc3920bis, but my
>>> question now is: how do existing clients and servers handle this?
>> We do this on the server side with a separate cert for each domain --
>> even conference, users, and other sub-domains used in s2s. Some client
>> software packages present a warning when certificates aren't correct
>> (domain mismatch, etc) but many do not and just use the certificates for
>> encryption, not authentication.
> 
> Let's say you are DreamHost, which has offered jabber services for years
> now. You want to offer secure connections. But you host 50,000+ domains.
> Are you going to have a separate certificate for each of those domains?
> Or let's say you are Internet2 and you want to offer XMPP services for
> all member universities, of which there are several hundred. Here again,
> are you going to have a separate cert for each domain, or one cert with
> all the possible virtual hosting domains as CNs and/or id-on-xmppAddr
> subjectAltNames?
> 

You can only have one common name in a certificate(I think). I don't see 
what the limit of subjectAltnames is in rfc3280 but you can do wildcards.

Managing 50k private keys would be nuts. Client support for traversing 
50k subjectAltNames would be questionable.

Obtaining an intermediate 
CA(http://www.geotrust.com/products/client_certificates/true_credentials.asp) 
from someone like GeoTrust or getting a wildcard 
cert(http://www.geotrust.com/products/ssl_certificates/wildcards.asp) 
might help. They might want to contact CACert.

So I'm all for each domain having their own certificate. Also the 
revocation list might be annoying if you have all 50k domains in one 
cert and you have to add one domain one day and delete a domain the next 
day...

-Jonathan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3252 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://www.jabber.org/jdev/attachments/20060301/27c574f4/attachment-0002.bin>