[Operators] server certs for XMPP and SIP

Daniel Pocock daniel at pocock.com.au
Fri Jan 27 22:59:59 UTC 2012



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
>>
>> http://tools.ietf.org/html/rfc6120
>> http://tools.ietf.org/html/rfc6125
> 
> Correct.

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'

> 
>> - the xmpp.net page found by Google only refers to the StartCom CA:
>>
>> http://xmpp.org/resources/certificates/
> 
> 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?

>> - the wiki page found by Google appears to be concerned with the old
>> standard:
>> http://wiki.xmpp.org/web/XMPP_Server_Certificates
>>
>> - 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

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?




oid_section             = new_oids

[ new_oids ]

# RFC 3920 section 5.1.1 defines this OID

xmppAddr = 1.3.6.1.5.5.7.8.5

SRVName = 1.3.6.1.5.5.7.8.7

[ req ]

default_bits            = 2048
default_keyfile         = test.key
distinguished_name      = distinguished_name
req_extensions          = v3_extensions
x509_extensions         = v3_extensions

# don't ask about the DN
prompt = no

[ distinguished_name ]

countryName                     = GB
stateOrProvinceName             = England
localityName                    = London
organizationName                = Example Limited

commonName                      = example1.com

[ v3_extensions ]

# for certificate requests (req_extensions)
# and self-signed certificates (x509_extensions)

basicConstraints                = CA:FALSE
keyUsage                        = digitalSignature,keyEncipherment
subjectAltName                  = @subject_alternative_name

[ subject_alternative_name ]

DNS.0                             = example1.com
otherName.0                       =
SRVName;IA5STRING:_xmpp-server.example1.com
otherName.1                       =
SRVName;IA5STRING:_xmpp-client.example1.com

DNS.1				  = example2.com
otherName.2			  = SRVName;IA5STRING:_xmpp-server.example2.com
otherName.3			  = SRVName;IA5STRING:_xmpp-client.example2.com

# this is only for SIP
DNS.2				  = example3.com




More information about the Operators mailing list