Using OpenSSL 1.x and Apache httpd 2.4.x, I've been trying to get OCSP
Stapling to work with both an RSA cert and an ECC cert configured. The
desired behaviour is (obviously) that httpd should staple the correct
OCSP Response for whichever cert (RSA or ECC) it chooses to send to the
client. However, I've found that it always staples the OCSP Response
for the ECC cert, even when it sends the RSA cert.
ssl_util_stapling.c in httpd 2.4.x calls SSL_get_certificate(), but this
function appears to have no knowledge of which server cert will actually
be sent to the client. I've been trying to work out how to fix the
httpd code, but it doesn't look like the OpenSSL API provides a clean
solution.
The ssl_get_server_send_cert() function defined in ssl_lib.c would be
ideal here, but since it's declared in ssl_locl.h it's not intended to
be available to applications.
But even if ssl_get_server_send_cert() was publicly accessible, I don't
think it would actually work properly. The Stapling Callback function
(s->ctx->tlsext_status_cb) is called when parsing the ClientHello
message, which I believe takes place before the server has decided which
cipher to use. And ssl_get_server_send_cert() needs to know which
cipher has been selected.
Is there a way to patch httpd so that it can work around the limitations
in the OpenSSL API and always send the correct OCSP Response?
Possible changes to OpenSSL:
Should the Stapling Callback function be called later in the handshake
(perhaps in ssl_add_serverhello_tlsext()), after the cipher has been
selected?
Should ssl_get_server_send_cert() be made available for applications to
call? Or should SSL_get_certificate() be updated so that it always
returns the cert that the server will actually send?
Thanks.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
