[Operators] wildcard cert
jesse.thompson at doit.wisc.edu
Tue Feb 23 09:43:06 CST 2010
On 2/23/2010 5:19 AM, Mitchel Constantin wrote:
> 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:
Thanks for the information Mitchel. It's good to know that GoDaddy will
work as an alternative to StartCOM.
Although, as you have probably noticed, my position on the issue has
changed somewhat. I was comfortable with using a wildcard certificate
that was signed by the XSF intermediary CA, since it could only be used
for the purposes of XMPP in practice. I'm not convinced that it is
appropriate to obtain a "real" wildcard certificate for this purpose.
> On Tue, Feb 23, 2010 at 1:28 AM, viq <vicviq at gmail.com
> <mailto:vicviq at gmail.com>> wrote:
> On Mon, Feb 22, 2010 at 9:26 PM, Jesse Thompson
> <jesse.thompson at doit.wisc.edu <mailto:jesse.thompson at doit.wisc.edu>>
> > 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
> >> 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,
> >> 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
> > 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
> > 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: jesse.thompson at doit.wisc.edu
> <mailto:jesse.thompson at doit.wisc.edu>
> Weavver, Inc.
Division of Information Technology, University of Wisconsin-Madison
Email/IM: jesse.thompson at doit.wisc.edu
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3317 bytes
Desc: S/MIME Cryptographic Signature
More information about the Operators