> 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?
Well, they certainly have separate certificates for https. For hosting providers it's usually an up-sell to your customers to add security on their http domains through a certificate purchased from an affiliate CA. I could easily see XMPP following the same route and/or using the same certificates. As a hosting provider I'd want separate certificates for all of my virtual domains so I could more easily provision domains on servers. I'd also want wildcard or multi-domain certificates for XMPP, but that wouldn't be necessary if, for example, S2S isn't enabled. -JD
