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
