< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index  

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


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@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel


_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel