[reSIProcate] Resiprocate TLS Server and Support for Sending Certificate Chains
Scott Godin
sgodin at sipspectrum.com
Sat Mar 26 14:21:01 CDT 2011
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20110326/07fcd8d9/attachment.htm>
More information about the resiprocate-devel
mailing list