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

[Aron Rosenberg]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20110327/db6ff44f/attachment.htm>