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?


Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
OpenSSL Project                       
Development Mailing List             
Automated List Manager                 

Reply via email to