[SR-Users] Wildcard TLS

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


-- 
Iñaki Baz Castillo
<ibc at aliax.net>