Using SSL_CTX_use_serverinfo_file() with multiple certs can lead to unexpected handshake failure

[Castaglia]

When SSL_CTX_use_serverinfo_file() is used to configure custom TLS extension data for an SSL_CTX, e.g. SCT data, and that SSL_CTX has been configured with multiple certificates via SSL_CTX_use_certificate(), strange things can happen.

To illustrate, assume a SSL_CTX which has been configured with a serverinfo file for TLS extension type 18, and two server certificates: first an RSA certificate, then an EC certificate. With such a server setup, using openssl s_client to request the configured TLS extension might work:

$ openssl s_client -connect 127.0.0.1:8443 -cipher ECDSA -serverinfo 18
CONNECTED(00000003)
-----BEGIN SERVERINFO FOR EXTENSION 18-----
...

or it might not:

$ openssl s_client -connect 127.0.0.1:8443 -cipher RSA -serverinfo 18
CONNECTED(00000003)
140735089771344:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:769:

It turns out that by requesting the TLS extension type 18 in the handshake, the handshake fails for the first configured server certificate, but succeeds for the last configured server certificate.

Once this bug is fixed, another unexpected behavior surfaces: the TLS extension data is only returned when the last configured server certificate is used. It looks like this happens because SSL_CTX_use_serverinfo_file(), meant to configure the TLS extension data for the entire SSL_CTX, only copies that data into the currently configured cert (i.e. ctx->cert->key->serverinfo). But when TLS extension data is retrieved, it's done using the cert->pkeys array. Adding another server certificate adds another entry to the cert->pkeys array and changes ctx->cert->key, but does not copy/preserve any configured serverinfo data.

This behavior was noticed as part of diagnosing this StackOverflow issue: http://serverfault.com/q/758482/253490

[mattcaswell]

This should be fixed now.