[Operators] server certs for XMPP and SIP
stpeter at stpeter.im
Mon Jan 30 02:36:42 UTC 2012
On 1/27/12 3:59 PM, Daniel Pocock wrote:
> On 27/01/12 23:38, Peter Saint-Andre wrote:
>> On 1/27/12 3:11 PM, Daniel Pocock wrote:
>>> I've got two questions:
>>> - what are the specifications for a subjectAltName (SAN) cert that can
>>> be used for both Jabber and SIP?
>>> - which CAs have been reliable in providing such certs?
>>> Background info that I found:
>>> - I understand the certs used to differ (SIP used the dNSName record
>>> type, while Jabber used otherName xmppAddr)
>>> - since the revised RFC 6120, Jabber now supports dNSName, same as SIP
> So my understanding of that is that the cert that works for Jabber will
> also work for SIP (and even SMTP) on the same domain
> However, I also understand that SIP and Jabber are verifying the domain
> portion of the JID and SIP address, whereas SMTP over TLS is only
> verifying the hostname - so it is necessary to either pay for an extra
> subjectAltName (if the MX record points to mail.example.com) or make
> sure the MX record for example.com points to a host called `example.com'
There's an "if" in there. :)
If you want mail.example.com and voip.example.com and im.example.com and
www.example.com or whatever, you'll either need to obtain one wildcard
certificate ("*.example.com") or four non-wildcard certificates (one for
each service you're running). Typically you need to pay for wildcard
certs (e.g., at StartCom you need to get certified and you need to pay
for that), whereas in some situations domain certs are free (but then of
course you're "paying" by needing to manage multiple certs). It's up to you.
>>> - the xmpp.net page found by Google only refers to the StartCom CA:
>> The reference to StartCom is there because we used to run an
>> intermediate CA with StartCom as the root. We've since terminated that
>> experiment, but StartCom is still popular among XMPP server admins.
> Would you know if they support the new method, as per RFC 6120?
I'd need to double-check, but I think they support DNS-IDs.
>>> - the wiki page found by Google appears to be concerned with the old
>>> - many of the CA web sites just refer to `subjectAltName' or SAN
>>> certificates - they don't advise what type of data (e.g. otherName or
>>> dNSName) they are willing to put in the cert
>> I've not had time to do any research about certification authorities, so
>> I'm not sure about the current state of the art among big CAs like
>> Thawte, Equifax, and GoDaddy. Sounds like a good topic for discussion
>> here. :)
> I made up a CSR (see my openssl.cnf below) and tried feeding it into
> Geotrust's registration wizard
Just FYI, I know that not all CAs accept all the data you might put in
CSRs (I know StartCom doesn't -- they have you input information into
their wizard and they create what they think is right -- I think they
might be worried about needing to check the entire CSR, but I'm not sure).
> It found the DNSName entries but ignored everything else
> Could you also comment on what I should use for `commonName' when I'm
> using subjectAltName? Should commonName just repeat one of the other
> names? Should it be the hostname where the cert is installed (e.g.
> bighost.example.com) or is there some other recommendation, or it just
> doesn't matter?
When I was working on RFC 6125, I really tried to convince the CAs to
deprecate Common Names, but they weren't quite ready to do so. Most
people put the basic domain name in the CN.
More information about the Operators