TL;DR : If you are a system administrator for infrastructure using X.509/PKI certificates, please check that your infrastructure doesn't depend on the following CA certificates to be trusted. Although their validity dates indicate they are still valid, they will be removed in upcoming software updates. If you depend on them, you are likely to experience failures. Talk to your CA and make sure you refresh affected certificates on your systems.


In order to avoid weak signing keys in the PKI trust infrastructure used by the global web, several CA certificates with weak 1024-bit keys have been removed by the maintainers of the Mozilla CA certificate list.

The current cleanup of 1024-bit keys affects the CA certificates with the following properties:

CN=Entrust.net Secure Server Certification Authority,OU=(c) 1999 Entrust.net Limited,OU=www.entrust.net/CPS incorp. by ref. (limits liab.),O=Entrust.net,C=US
SHA1 Fingerprint: 99:A6:9B:E6:1A:FE:88:6B:4D:2B:82:00:7C:B8:54:FC:31:7E:15:39

E=info@valicert.com,CN=http://www.valicert.com/,OU=ValiCert Class 1 Policy Validation Authority,O="ValiCert, Inc.",L=ValiCert Validation Network
SHA1 Fingerprint: E5:DF:74:3C:B6:01:C4:9B:98:43:DC:AB:8C:E8:6A:81:10:9F:E4:8E

E=info@valicert.com,CN=http://www.valicert.com/,OU=ValiCert Class 2 Policy Validation Authority,O="ValiCert, Inc.",L=ValiCert Validation Network
SHA1 Fingerprint: 31:7A:2A:D0:7F:2B:33:5E:F5:A1:C3:4E:4B:57:E8:B7:D8:F1:FC:A6

E=info@valicert.com,CN=http://www.valicert.com/,OU=ValiCert Class 3 Policy Validation Authority,O="ValiCert, Inc.",L=ValiCert Validation Network
SHA1 Fingerprint: 69:BD:8C:F4:9C:D3:00:FB:59:2E:17:93:CA:55:6A:F3:EC:AA:35:FB

These removals happened in version 2.1 (2014) of the CA certificates list, which has been published as part of the NSS release 3.16.3 and which has been amended in 3.16.4.

The upcoming Firefox 32 release, which is expected around September 2nd, 2014, will use this cleaned up list.

Since many other open source software packages or operating systems have chosen to use the Mozilla CA list as the base for global Internet trust, the list is widely distributed, and you should expect software updates with these removals. For example, this affects the ca-certificates package in the Fedora Linux distribution.

To analyze if you depend on the CA certificates listed above, for example, you could check which trust chain is presented when connecting to your server. For example, you could try to use a command like this to retrieve the certificates sent by the server:

$ openssl s_client -showcerts -connect kuix.de:443

Update 2
The output of the above command will display the issuer and subject names of all certificates sent by the server. If one of the issuer names matches with a name in the removal list, then you could be affected. The full check requires additional effort. It depends on your software, whether it will build a trust-chain to one of the removed CA certificates - which will fail after the removal. The names alone cannot tell, because replacement intermediate CA certificates might exist, with identical names, but different (good) properties.

When in doubt, check with your CA. Alternatively, you could configure a test system to no longer trust the removed CA certificates, and see if a connection (or a certificate validation) fails.

(In an earlier version of this blog post, I had suggested a check that doesn't work. It doesn't work to compare fingerprints of certificates sent by a server, with fingerprints shown in the list, because servers don't send the root CA certificate, but only intermediate CA certificates. I apologize for my earlier mistake in thinking.)
end of Update 2

If you find a certificate shown in the above list, then you should work with your CA to get a replacement certificate quickly, and update the configuration of your infrastructure. In some scenarios it may be sufficient to replace the intermediate CA certificate configured on a server, which allows clients to find an alternative chain of trust to a different server. Please ask your CA for details, if such an intermediate CA certificate is available, or if you must update to a refreshed server certificate (including the respective, different intermediate CA certificates).

As an example, several web sites have been found to still use an intermediate CA certificate with the following subject:

CN=USERTrust Legacy Secure Server CA,O=The USERTRUST Network,L=Salt Lake City,ST=UT,C=US

which had been issued by the removed Entrust.net CA certificate. (Note that Entrust.net hasn't been removed completely, only an older certificate with a weak 1024-bit key.)

In order to limit the impact of the removal, this CA has issued a replacement intermediate CA certificate, which has been signed by another CA certificate with a stronger key. This intermediate certificate has been included in the Mozilla CA policy list, with neutral trust settings, intended as a helper certificate, that can allow software to find the path to a different trusted root.

However, only a limited number of software libraries performing X.509 certificate validation are able to make use of this helper certificate in their default configuration. For example, the NSS library will notice the replacement intermediate CA certificate being present in the certificate store, and because the replacement certificate has been configured by the CA to contain newer validity timestamps, it will be preferred by NSS, and the chain to another CA certificate with a stronger 2048-bit key will be found.

It seems that applications based on OpenSSL and GnuTLS typically don't use the replacement intermediate certificate, even if it's available in a certificate store during the validation. Therefore it's important to configure servers to send the correct intermediate CA certificate.

Note this is a first batch of removals of 1024-bit CA certificates. The Mozilla CA certificate list still contains entries with weak 1024-bit, and there are plans to remove them in future updates. If you'd like to learn more or discuss these changes, please refer to Mozilla's dev-security-policy discussions list.

Please help to distribute this information. Thank you.


UPDATE

While we have your attention, here is a list of additional weak 1024-bit CA certificates that are planned to be removed at a later time. If you depend on them, make sure you start to work with your CA to get them refreshed by your CA, too.

GTE CyberTrust Global Root, GTE CyberTrust Solutions, Inc., GTE Corporation, US
SHA1: 97:81:79:50:D8:1C:96:70:CC:34:D8:09:CF:79:44:31:36:7E:F4:74

Thawte Consulting cc, Certification Services Division, Thawte Server CA
SHA1 Fingerprint: 23:E5:94:94:51:95:F2:41:48:03:B4:D5:64:D2:A3:A3:F5:D8:8B:8C

Thawte Consulting cc, Certification Services Division, Thawte Premium Server CA
SHA1 Fingerprint: 62:7F:8D:78:27:65:63:99:D2:7D:7F:90:44:C9:FE:B3:F3:3E:FA:9A

VeriSign, Inc., VeriSign Trust Network, VeriSign Class 3 Public PCA – G2
SHA1 Fingerprint: 85:37:1C:A6:E5:50:14:3D:CE:28:03:47:1B:DE:3A:09:E8:F8:77:0F

Equifax Secure Inc., Equifax Secure eBusiness CA-1
SHA1 Fingerprint: DA:40:18:8B:91:89:A3:ED:EE:AE:DA:97:FE:2F:9D:F5:B7:D1:8A:41

Equifax Secure Certificate Authority, Equifax Secure CA
SHA1 Fingerprint: D2:32:09:AD:23:D3:14:23:21:74:E4:0D:7F:9D:62:13:97:86:63:3A

Equifax Secure Inc., Equifax Secure Global eBusiness CA-1
SHA1 Fingerprint: 7E:78:4A:10:1C:82:65:CC:2D:E1:F1:6D:47:B4:40:CA:D9:0A:19:45