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 viperdudeuk@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.
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.
[...]
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).
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.