On 22.04.2014 12:55, Yann Ylavic wrote: > On Mon, Apr 21, 2014 at 8:39 AM, <[email protected]> wrote: >> +#ifdef SSL_CERT_SET_SERVER >> + /* >> + * When multiple certs/keys are configured for the SSL_CTX: make sure >> + * that we get the private key which is indeed used for the current >> + * SSL connection (available in OpenSSL 1.0.2 or later only) >> + */ >> + SSL_set_current_cert(ssl, SSL_CERT_SET_SERVER); >> +#endif > > Shouldn't this be fixed in OpenSSL (1.0.2)?
That's probably a question for Steve, but the way I understood his comment in February was that he would rather not want it to do by default, hence the new SSL_CERT_SET_SERVER control. > When SSL_CTX_set_current_cert(ctx, SSL_CERT_SET_FIRST|NEXT) is used to > scan the certs, should one use a final SSL_CTX_set_current_cert(ctx, > SSL_CERT_SET_SERVER) so that the one "inherited" by SSL_new(ctx) (if > any) gets set accordingly? That's not possible - for SSL_get_privatekey, we do not know which cert is picked at connection time (the client can influence this by the cipher suites he offers in the ClientHello). > Or every callback ought to take care of this? Unless OpenSSL does it by default (or the SSL_CTX only uses a single cert), we have to set it with SSL_set_current_cert, yes. > How about TmpDH used by client (proxy) handshake, is still > SSL_CERT_SET_SERVER the right cert? SSL_CTX_set_tmp_dh_callback() - which we use for setting ssl_callback_TmpDH - applies to a server-mode SSL_CTX only. > It looks like a regression to me (which may affect several software), > the callbacks should not care about the loading order of (or previous > walking though) the certs, and the callback's given SSL current cert > be the one of the underlying authentication. I think it boils down to my question from February, in the end ([1], "Could ssl_lib.c:ssl_get_server_send_pkey be adapted to ensure this?") Kaspar [1] https://mail-archives.apache.org/mod_mbox/httpd-dev/201402.mbox/%[email protected]%3E
