[SR-Users] Wildcard TLS

[Klaus Darilion]

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 at 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.
> 
>