Hi Iñaki, Thank you very much for sharing this information. I check the same in my server implementation with various SIP clients and hope this should work out.
Best Regards, Vivek Batra -----Original Message----- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Iñaki Baz Castillo Sent: Monday, June 13, 2011 9:58 PM To: Kevin P. Fleming Cc: sip-implementors@lists.cs.columbia.edu Subject: [Spam] :Re: [Sip-implementors] CN field in Server Certificate during SIP TLS call when server is connected behind the NAT router 2011/6/13 Kevin P. Fleming <kpflem...@digium.com>: > Yes, it is. In addition, if the IP-PBX is generating certs with IP > addresses in them, or is provisioned with them, and the IP-PBX is behind > a NAT and has multiple 'identities' that UAs could see, then it should > be provisioned with multiple certificates and respond with the proper > one based on the source address of the incoming connection (or > destination address of an outgoing connection). Note that, in case of multi-domain, it's not required at all to have multiple TLS certificates, as the same TLS certificate can contain various SIP domains in the SubjetAltName. RFC 5922 (TLS certificates in SIP) which updates RFC 3261, states: 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). -- Iñaki Baz Castillo <i...@aliax.net> _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
