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

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


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