25 May
2011
25 May
'11
4:15 p.m.
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(a)gmail.com>om>:
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.