[reSIProcate] Resiprocate TLS Server and Support for Sending Certificate Chains

[Scott Godin]

Hi Aron,

Thanks for the feedback.

I'm pretty sure the Lync Edge server allows a different certificate per
interface - generally a public cert is used on the external interface and a
private one on the internal interface.  I would like to support this
scenario, when using repro as an edge server, so I don't think a global
SSL_CTX will work.  Also a change like that would not be back compatible for
people currently using different domain certificates per
transport/interface.

Regards,
Scott

On Sun, Mar 27, 2011 at 1:56 PM, Aron Rosenberg <arosenberg at logitech.com>wrote:

> Scott,
>
> You could always keep the single global TLS SSL_CTX and just require use of
> multiple SubjAltName certificates with repro. RFC 5922 seems to mostly
> mandate this usage anyway. Not that it matters, but this is the standard
> deployment pattern with Microsoft Office Communicator server (lync) for its
> SIP components.
>
> -Aron
>
> Aron Rosenberg
> Sr. Director, Engineering
> Logitech Inc. (SightSpeed Group)
>
>
>
> On Sat, Mar 26, 2011 at 12:21 PM, Scott Godin <sgodin at sipspectrum.com>wrote:
>
>> Hi All,
>>
>> I've recently come to realize that resip's TLS transports (server side)
>> are only capable of providing a single certificate to TLS clients.  They are
>> not currently capable of sending a chain of certificates in the TLS
>> handshake.
>>
>> I'm looking at addressing this issue.  I'm not an OpenSSL expert, so I'd
>> like to bounce my plans off the list, to see if there are any concerns.
>>
>> One of the problems with implementing this support is that all of the
>> OpenSSL API's to provide multiple certificates to use in a TLS server
>> operate on the SSL_CTX level.   Resip uses a global SSL_CTX implemented in
>> the Security class, for all Tls Transports.  Currently we provide domain
>> certificates to TLS transports on the SSL object (there is one SSL object
>> per TLS transport).  However there are no API's to provide a certificate
>> chain at the SSL object level.  Given all this, the only way I can see to
>> implement an ability to present a certificate chain, and to be able to
>> present a different chain per Tls Transport/domain - we need to do the
>> following:
>> 1.  Stop using the global SSL_CTX that is created in the Security class,
>> and instead create an SSL_CTX per Tls transport (note:  this is what the
>> Dtls transport already does).
>> 2.  This new per-transport SSL_CTX will need to have the same settings
>> that are currently used on the global one, ie:
>>   - SSL_CTX_set_cert_store to Security::mRootTlsCerts (required for
>> validating outbound/client TLS/MTLS connections)
>>   - SSL_CTX_set_verify to Security::verifyCallback (required for
>> validating outbound/client TLS/MTLS connections)
>>   - SSL_CTX_set_cipher_list to Security::CipherList - to limit the
>> supported Ciphers supported
>> 3.  This new per-transport SSL_CTX will need to use one of the following
>> two API sets in order to assign the certificate chain:
>>  - SSL_CTX_use_certificate, and SSL_CTX_add_extra_chain_cert     OR
>>  - SSL_CTX_use_certificate_chain_file (I'm currently leaning towards this
>> API as we won't need a new mechanism to load individual certs to be added to
>> the chain)
>>
>> Please let me know if you can think of any negative impacts to these
>> changes, or if you know of a better way to implement this.
>>
>> Regards,
>> Scott
>>
>> _______________________________________________
>> resiprocate-devel mailing list
>> resiprocate-devel at resiprocate.org
>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20110328/bc4da314/attachment.htm>