Enhancement request. I suggest to enhance the trust chain discovery used by openssl, when verifying a SSL/TLS server certificate, to make it work with a popular server configuration.
Recently, Mozilla has started to cleanup the Mozilla CA trust list and remove CA certificates that use a weaker 1024-bit RSA key. I'll call them legacy CAs. When upgrading the trust store used by openssl to exclude the legacy CA certificates, by default, openssl (e.g. s_client) can no longer verify the server certificate of several popular SSL/TLS servers, examples are www.flickr.com and www.amazon.com. The reason is the approach that CA organizations have used for a smooth rollover from legacy CA certificates to more recent CA certificates (with stronger keys). That approach is compatible with the NSS library, and also with recent versions of the GnuTLS library (e.g. version 3.3.10). The approach works like explained in the following simplified example. Let's say we have: - a legacy CA, self-signed, with issuer/subject name: OLD-CA-1024 - an intermediate CA, with subject name NEW-CA-2048, signed by the issuer OLD-CA-1024. - a server certificate, with subject name www.server, signed by the issuer NEW-CA-2048. In the past, only OLD-CA-1024 was included in the Mozilla CA trust list. When the above chain is found, the www.server certificate can be verified. In addition to the above, the CA organization creates another certificate, an alternative version of the NEW-CA-2048 certificate, which is based on the same public/private key pair, but which is self signed (issuer and subject names are both NEW-CA-2048). The CA has worked with Mozilla to get the self-signed version of NEW-CA-2048 included in the Mozilla trust list. When trusting NEW-CA-2048, this CA certificate is sufficient to find a valid issuer chain for www.server. In practice, the OLD-CA-1024 certificate and the issued certificates have a remaining lifetime of up to several years, but the web server configurations are keeping their old configuration. They still send the intermediate CA version of the NEW-CA-2048 certificate, which is signed by OLD-CA-1024. This is done for two reasons. First, it is helpful for enhanced compatibility, the server can work with client software that trusts OLD-CA-1024, only, and which hasn't been upgraded to trust the self-signed version of NEW-CA-2048. Second, there are many administrators who aren't updating their servers, because their server certificate is still valid. This means, those servers will keep sending the intermediate CA version of NEW-CA-2048 in the SSL/TLS handshake. In order to function correctly with those servers when using the cleaned up trust list (OLD-CA-1024 removed), it is necessary that client software attempts to discover more than one version of a trust chain. In particular, it should be able to ignore an unnecessary intermediate sent by the server, in order to find a shorter trust path. However, by default, openssl will not find the shorter path, and will reject the server certificate, e.g. reporting the inability to get the issuer certificate. Unfortunately, this current default behaviour of openssl blocks the removal of the legacy CA certificates with weaker keys from the CA trust list, because many existing applications use the openssl default, and removing the legacy CAs would cause the applications to fail connecting to the affected servers. Therefore I'd like to suggest to change the openssl default behaviour, to make it possible to allow client applications to be compatible with the above scenario, by upgrading to a newer version of the openssl library. When discussing this issue, my colleague Hubert Kario made me aware of a flag offered by e.g. the openssl s_client utility: "-trusted_first". When using -trusted_first, the server verification works successfully in the above scenario. Given that the suggestion is to change openssl's default behaviour, changing openssl to use the -trusted_first mode by default might potentially be a solution. However, it's not obvious if this mode could have other side effects that are undesirable. Therefore I suggest to discuss which approach is best to support the removal of legacy CAs, either by changing the default of the -trusted_first setting, or by implementing another solution. I think it would be good to find a solution that could be backported to the openssl 1.0.1 branch. Thanks in advance for discussing and working on this issue. Kai ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
