I'm joining this conversation late, but I just set up a wildcard ssl cert last week. It might be worth mentioning to admins that you can re-use the same SSL certificate that you use for your website for your XMPP server. I wrote a short blog about my experience: http://www.weavver.com/Company/Marketing/Blogs/?bid=69631d7b5c9d7de53077f3a6dcb11e38
<http://www.weavver.com/Company/Marketing/Blogs/?bid=69631d7b5c9d7de53077f3a6dcb11e38> Cheers, Mitchel On Tue, Feb 23, 2010 at 1:28 AM, viq <[email protected]> wrote: > On Mon, Feb 22, 2010 at 9:26 PM, Jesse Thompson > <[email protected]> wrote: > > On 2/22/2010 12:43 PM, Peter Saint-Andre wrote: > >> > >> On 2/22/10 11:27 AM, Jesse Thompson wrote: > >> > >>> We might as well stick with this clusterf*ck until xmpp-dna or > >>> xmpp-delegate is implemented. > >> > >> Oh, and even then you're going to require a certificate, no? The point > >> of DNA or _xmpp-delegate or whatever solution the XMPP WG comes up with > >> is to handle the case of delegation (e.g., Google Apps is hosting my > >> domains) or the case of adding multiple domains to an existing > >> connection via attribute certificates. And the attribute cert stuff is > >> going to require a lot of man hours -- new features in OpenSSL or the > >> like, an admin-friendly and open-source tool to generate attribute certs > >> because otherwise it will be really hard, best practice docs, READMEs, > >> etc. Who is going to do all that work? TANSTAAFL, folks. > > > > Yes, we're stuck with a bunch of crappy alternatives: > > > > 1. wildcard certificates won't match all virtual domains and also don't > > match the vcards/conference components within subdomains, introduce > security > > risks if the private keys are exposed, and can be difficult to obtain for > > many organizations > > Don't at least ejabberd and prosody have support for per-domain certs? > That sounds like what you're looking for. > > > 2. xmpp-dna appears that it will be complicated to understand and/or > > implement > > > > 3. xmpp-delegate would be perfect if we had DNSSEC or some out of band > > method of assuring the accuracy of DNS > > > > 4. using mismatched or self-signed certificates shows warnings to users, > but > > most clients have been developed to make it easy for users to bypass the > > warnings. > > > > Given these alternatives, #4 seems to be the pragmatic solution. > > > > Jesse > > > > -- > > Jesse Thompson > > Division of Information Technology, University of Wisconsin-Madison > > Email/IM: [email protected] > > > > > > > > -- > viq > -- Weavver, Inc.
