Phasing out Certificates with 1024-bit RSA Keys

For many years, Mozilla, NIST, the CA/Browser Forum, and others have been encouraging Certification Authorities (CAs) to upgrade their 1024-bit RSA keys to a stronger cryptographic algorithm (either longer RSA keys or ECDSA). We are actively working with CAs to retire SSL and Code Signing certificates that have 1024-bit RSA keys in an effort to make the upgrade as orderly as possible, and to avoid having system administrators find themselves in emergency mode because their SSL keys were compromised. Our multi-pronged approach includes removing the SSL and Code Signing trust bits from 1024-bit root certificates in NSS, gathering telemetry about end-entity certificates with 1024-bit RSA keys, and then eventually showing an “Untrusted Connection” error when a certificate in the chain has an RSA key that is less than 2048 bits.

To help with migration off of 1024-bit root certificates, we are making changes in phases. The first phase involved removing or turning off trust bits for the following 1024-bit root certificates in Firefox 32.

In Firefox 32, the following 1024-bit CA certificates were either removed, or their SSL and Code Signing trust bits were turned off:

• Entrust
  • CN = Entrust.net Secure Server Certification Authority
  • SHA1 Fingerprint: 99:A6:9B:E6:1A:FE:88:6B:4D:2B:82:00:7C:B8:54:FC:31:7E:15:39
• SECOM
  • OU = ValiCert Class 1 Policy Validation Authority
  • SHA1 Fingerprint: E5:DF:74:3C:B6:01:C4:9B:98:43:DC:AB:8C:E8:6A:81:10:9F:E4:8E
• GoDaddy
  • OU = ValiCert Class 2 Policy Validation Authority
  • SHA1 Fingerprint: 31:7A:2A:D0:7F:2B:33:5E:F5:A1:C3:4E:4B:57:E8:B7:D8:F1:FC:A6
• EMC / RSA
  • OU = ValiCert Class 3 Policy Validation Authority
  • SHA1 Fingerprint: 69:BD:8C:F4:9C:D3:00:FB:59:2E:17:93:CA:55:6A:F3:EC:AA:35:FB
• Symantec / VeriSign
  • OU = Class 3 Public Primary Certification Authority
  • SHA1 Fingerprint: A1:DB:63:93:91:6F:17:E4:18:55:09:40:04:15:C7:02:40:B0:AE:6B
  • OU = Class 3 Public Primary Certification Authority
  • SHA1 Fingerprint: 74:2C:31:92:E6:07:E4:24:EB:45:49:54:2B:E1:BB:C5:3E:61:74:E2
• NetLock
  • CN = NetLock Uzleti (Class B) Tanusitvanykiado
  • SHA1 Fingerprint: 87:9F:4B:EE:05:DF:98:58:3B:E3:60:D6:33:E7:0D:3F:FE:98:71:AF
  • CN = NetLock Expressz (Class C) Tanusitvanykiado
  • SHA1 Fingerprint: E3:92:51:2F:0A:CF:F5:05:DF:F6:DE:06:7F:75:37:E1:65:EA:57:4B

If you run an SSL-enabled website, this change will not impact you if your certificates and the CAs above it have 2048-bit keys or more. If your SSL certificate has a 1024-bit key, or was issued by a CA with a 1024-bit key, then you will need to get a new SSL certificate, and update the certificates in your Web server. If the intermediate certificate that you are using has a 1024-bit key, then you will need to download the 2048-bit intermediate certificate from the CA, and update the certificate chain in your Web server. For your convenience, links to the impacted CAs are provided in the list above.

The second phase of migrating off of 1024-bit root certificates involves the changes identified in Bugzilla Bug #986014 and Bug #1047011. The root certificates under consideration for the second phase are Thawte, VeriSign, Equifax, and GTE CyberTrust 1024-bit root certificates. These root certificates are operated by Symantec and Verizon Certificate Services, and we are planning these changes to be released in Firefox in early 2015. As always, these root certificate changes will be discussed in the mozilla.dev.security.policy forum.

The third and final phase of migrating off of 1024-bit root certificates involves the changes identified in Bugzilla Bug #986019, which relates to Equifax root certificates that are owned by Symantec. The plan for the third phase of 1024-bit root changes will be discussed in the mozilla.dev.security.policy forum. We are targeting to complete the migration off of 1024-bit root certificates in the first half of 2015, after which no 1024-bit root certificates will be trusted to identify websites or software makers.

Please check your SSL certificates and replace any with 1024-bit RSA keys, and contact mozilla.dev.security.policy if you have comments or concerns.

Mozilla Security Engineering Team