Compatibility changes related to CA certificates with 1024-bit RSA keys

The Mozilla Foundation has been phasing out CA Certificates with 1024-bit RSA keys. For further background information, you may refer to the following Mozilla Security Blog articles:

https://blog.mozilla.org/security/2014/09/08/phasing-out-certificates-with-1024-bit-rsa-keys/
https://blog.mozilla.org/security/2015/01/28/phase-2-phasing-out-certificates-with-1024-bit-rsa-keys/

The involved CAs have been used to issue end entity certificates, such as SSL/TLS server certificates, and most of these issued certificates already use stronger keys. Because these issued certificates are still valid, many existing deployments on the public internet and on private intranets will continue to use their existing configuration until the certificates expire.

It is necessary to ensure that the process of phasing out 1024-bit CA certificates maintains compatibility with these deployments and does not require their immediate reconfiguration with replacement certificates.

The certificate authorities have prepared for the transition to newer CA certificates with stronger keys by using X.509 cross-certification.

A popular deployment example are SSL/TLS servers. When a client software connects to a server, the server presents its end entity certificate, along with all intermediate CA certificates required to find a chain of trust to a root CA certificate that is known to the client software. For maximum compatibility, many servers are still configured to include intermediate CA certificates that point to one of the legacy CA certificates with a 1024-bit key, in order to support client software that knows about and trusts exclusively these legacy CA certificates.

By contrast, client software that no longer trusts the legacy 1024-bit CA certificates must be able to ignore any unnecessary intermediate CA certificate that is sent by the server, in order to construct a shorter chain of trust to one of the newer replacement CA certificates.

The ability to automatically ignore unnecessary intermediate CA certificates, and to discover alternative chains of trust, has been supported by the Mozilla Firefox application and by the Network Security Services (NSS) library for several years already. This situation allowed Mozilla to remove trust for legacy CA certificates while keeping compatibility.

However, on Red Hat Enterprise Linux, the CA certificates list is not limited to Mozilla software, but it is used as a global list for many additional applications.

Unfortunately, when it became necessary to update the list of CA certificates in Red Hat Enterprise Linux to the version that removed the legacy CA certificates (version 2.4), the versions of the OpenSSL and GnuTLS software that were shipped as a part of Red Hat Enterprise Linux did not yet have the ability to automatically ignore unnecessary intermediate CA certificates, and to discover alternative chains of trust.

Specifically, OpenSSL and GnuTLS were only able to successfully verify chains of trust that involved the full set of intermediate CA certificates sent by the server. As a result, software applications that use the OpenSSL or GnuTLS libraries to implement SSL/TLS connectivity, and that no longer trust the legacy CA certificates, fail to verify the certificates of affected servers, and may by default reject connections to affected servers as untrusted and insecure.

Although the developers of the GnuTLS and OpenSSL projects have begun to work on enhancements to support these server configurations, enhanced software packages for Red Hat Enterprise Linux are not yet available at the time of writing of this article, nor were they available when the affected version 2.4 of the ca-certificates package was provided as a Red Hat Enterprise Linux update.

Thus, in order to avoid the effects of the incompatibility with the legacy removals, and to avoid regressions in SSL/TLS connectivity after ugprading the ca-certificates package, it has been decided to keep the legacy CA certificates trusted by default in the ca-certificates package, until enhanced OpenSSL and GnuTLS packages can be provided. This may or may not happen during the lifetime of the respective Red Hat Enterprise Linux version.

At the time of writing this article, no practicable attacks to 1024-bit RSA keys are known, and it has therefore been decided that keeping the legacy CA certificates trusted by default is currently acceptable.

Nevertheless, the removal decision made by Mozilla is a reasonable precaution. Therefore, users or system administrators of Red Hat Enterprise Linux systems might prefer to disable the legacy CA certificates regardless of the consequences.

In order to disable the modifications made to the ca-certificates package, as well as to deploy them on a Red Hat Enterprise Linux system, a new configuration mechanism may be used, which has been introduced as a part of the ca-certificates package version 2.4. The configuration must be performed on each individual Red Hat Enterprise Linux system where these changes are to be made.

The configuration can be done using the new ca-legacy command, which is documented at the ca-legacy(8) manual page.

Once the administrator changes the configuration to disable the legacy modification, the configuration is kept for future package upgrades of ca-certificates, which in the future might also affect CA certificates beyond the currently described 1024-bit sized certificates.

If the administrator does not make any changes and decides to keep the default configuration, future upgrades to the ca-certificates package may keep the legacy 1024-bit CA certificates enabled, or may keep additional groups of CA certificates enabled, if it is seen as reasonable by the package maintainers.

If, in such case, future updates to the OpenSSL and GnuTLS packages become available that remove the described limitiations and thus make it unnecessary to keep the legacy CA certificates trusted, then a future update of the ca-certificates package might change the contents of ca-certificates to no longer trust the legacy CA certificates by default.

It should be noted that each CA certificate may have different trust settings for different purposes, such as web sites and SSL/TLS servers, email encryption/signing, and code signing. Therefore, it is a simplicfiation to say that CA certificates might be removed or kept entirely.

For several legacy CA certificates with 1024-bit RSA keys, Mozilla has marked them as no longer trusted for SSL/TLS, although they are still marked as trusted for email security. In other words, several legacy CA certificates have not yet been removed by Mozilla, they only had portions of their trust removed. This is why the ca-certificates package contains two alternative files for legacy CA certificates, with two variations of trust flags, and cannot simply enable or disable a list.