Inaki - are there any SIP implementations which implemented RFC 5922? I suspect also Kamailio is not conform.
regards Klaus Am 25.05.2011 13:29, schrieb Iñaki Baz Castillo: > 2011/5/24 Jon Farmer <viperdud...@gmail.com>: >> I want to start offering TLS on a per customer basis. However I don't >> want to have to create a TLS certificate per customer if I don't need >> to. So I need to know if I can create a *.example.org certificate and >> use that for all customers who want TLS? > > Hi Jon, please check RFC 5922 "Domain Certificates in the Session > Initiation Protocol (SIP)" as you don't need a TLS certificate for > each domain you server (this is a common misunderstanding): > > > 7.3. Client Behavior > > A client uses the domain portion of the SIP AUS to query a (possibly > untrusted) DNS to obtain a result set, which is one or more SRV and A > records identifying the server for the domain (see Section 4 for an > overview). > > The SIP server, when establishing a TLS connection, presents its > certificate to the client for authentication. The client MUST > determine the SIP domain identities in the server certificate using > the procedure in Section 7.1. Then, the client MUST compare the > original domain portion of the SIP AUS used as input to the RFC 3263 > [8] server location procedures to the SIP domain identities obtained > from the certificate. > > > 7.1. Finding SIP Identities in a Certificate > > Implementations (both clients and server) MUST determine the validity > of a certificate by following the procedures described in RFC 5280 > [6]. > > [...] > > Given an X.509 certificate that the above checks have found to be > acceptable, the following describes how to determine what SIP domain > identity or identities the certificate contains. A single > certificate can serve more than one purpose -- that is, the > certificate might contain identities not acceptable as SIP, domain > identities and/or might contain one or more identities that are > acceptable for use as SIP domain identities. > > 1. Examine each value in the subjectAltName field. The > subjectAltName field and the constraints on its values are > defined in Section 4.2.1.6 of RFC 5280 [6]. The subjectAltName > field can be absent or can contain one or more values. > > [...] > > 2. If and only if the subjectAltName does not appear in the > certificate, the implementation MAY examine the CN field of the > certificate. If a valid DNS name is found there, the > implementation MAY accept this value as a SIP domain identity. > Accepting a DNS name in the CN value is allowed for backward > compatibility, but when constructing new certificates, consider > the advantages of using the subjectAltName extension field (see > Section 6). > > > 6. Certificate Usage by a SIP Service Provider > > It is possible for service providers to continue the practice of > using existing certificates for SIP usage with the identity conveyed > only in the Subject field, but they should carefully consider the > following advantages of conveying identity in the subjectAltName > extension field: > > o The subjectAltName extension can hold multiple values, so the same > certificate can identify multiple servers or sip domains. > > o There is no fixed syntax specified for the Subject field, so > issuers vary in how the field content is set. This forces a > recipient to use heuristics to extract the identity, again > increasing opportunities for misinterpretation. > > _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
