Closed Bug 986019 Opened 10 years ago Closed 9 years ago

Turn off SSL and Code Signing trust bits for Equifax 1024-bit roots

Categories

(NSS :: CA Certificates Code, task)

Product:
NSS
Component:
CA Certificates Code
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: kathleen.a.wilson, Unassigned)

References

Details

(Whiteboard: Websites and Code Signing Trust Bits turned off in Firefox 38)

Attachments

(1 file, 1 obsolete file)

Sites that use Equifax root and will be broken upon root cert removal
21.85 KB, text/plain
Details 
Please turn off the WebSites and Code Signing trust bits for the following 1024-bit root certificates owned by Symantec.

> Equifax	
> Equifax Secure Certificate Authority	
> Equifax Secure CA	
> 1998 Aug 22	
> 2018 Aug 22	
> SHA-1
> 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	
> 1999 Jun 21	
> 2020 Jun 21	
> MD5
> SHA1 Fingerprint: 7E:78:4A:10:1C:82:65:CC:2D:E1:F1:6D:47:B4:40:CA:D9:0A:19:45
Whiteboard: Target Firefox 35
Attached file final-986019-BAD_SITES.txt (obsolete) — 
This list of 256 sites was obtained by running over 200,000 top SSL-enabled sites against Fx32, compiled without these root certs. It is not guaranteed to be a list of all affected sites on the web, but should allow the CA to alert some customers of upcoming Fx changes.
Rick, please see the attached list of URLs to websites that fail when the changes in this bug are made.
Thanks; there are a lot more than 256 sites that chain up to these roots. We're working on notifying customers and getting them to move.
(In reply to Rick Andrews from comment #3)
> Thanks; there are a lot more than 256 sites that chain up to these roots.
> We're working on notifying customers and getting them to move.

FWIW the data source that I'm currently working with is made from top sites, which may not reflect the state of the majority on the web. I intend to re-run this compatibility test on a much larger data set of around a million sites, so that should be more helpful. It just takes more time. Stay tuned.
Related this: Bug #1037906
"12000 certificates that are still valid, haven't been revoked and have a 1024 bit key.  Over 1000 of those are still being used."
Rick, Please update this bug to let us know if it would make sense to temporarily directly include a cross-signed intermediate cert in order to help with the transition off of any of these 1024-bit roots.
The idea is that for sites that present a chain like this:
2048 bit host cert <- 1024 bit old sub CA <- 1024 bit root CA
we can find a certificate chain like this:
2048 bit host cert <- 2048 bit cross-signed sub CA <- 2048 bit root CA
where the cross-signed sub CA is temporarily shipped by NSS to help with the transition.

I know this won't help with the 1024-bit end-entity certs -- that will be handled in Bug #1049740.
Whiteboard: Target Firefox 35 → Target Firefox 37
Sorry for the delay. We do not wish to include a cross-signed intermediate cert for either of these roots. The vast majority of certs were signed directly from these roots.
Thanks, Rick.
We plan on this bug being part of the January batch of root changes, which will probably target FF 37.
Whiteboard: Target Firefox 37 → Target Firefox 38
Rick, data appears to indicate that the first root listed in this bug is still being very widely used. 
When was the last cert issued in this hierarchy?
https://apps.stevenson.edu seems to go to 2016-01-05(!).
Also https://www.tinytillia.com/ . Why was this issued in 2011?
Yuhong, I don't understand your question. The customer requested a cert and we issued it.
According to http://www.verisign.com/video/pdf/2048bit-root-migration-webinar.pdf GeoTrust was supposed to migrate during mid-2010.
(In reply to Yuhong Bao from comment #13)
(In reply to Yuhong Bao from comment #14)

Thanks for these pointers. So, apparently some people within the VeriSign/GeoTrust/Thawte world did know that they needed to be migrating off of their 1024-bit roots!

To bad nobody listened...

Just saying...
Yes, those pdfs describe when we began using new 2048-bit roots for all new cert issuance. Migrating the hundreds of thousands of existing customer certs that chained up to 1024-bit roots wasn't going to happen all at once, at that same time. In fact, if you read the full KB article you would see "There is no action necessary on the part of RapidSSL customers. Valid certificates issued off of 1024-bit RSA Roots will continue to operate correctly and securely. There is no need to replace existing certificates."

The vast majority of them were five-year certs. As they came up for renewal, their replacements were issued off of 2048-bit roots. I believe this is exactly what every other CA did, so I reject the implication that you caught us saying one thing and doing another.
Except that the certificate for https://www.tinytillia.com/ was *issued* during April 2011.
(In reply to Rick Andrews from comment #16)
> Yes, those pdfs describe when we began using new 2048-bit roots for all new
> cert issuance. 

If all new cert issuance had indeed been limited to the 2048-bit roots starting in May of 2010, then all of those 5-year certs would be expired or expiring soon. We wouldn't still have a huge number of valid certs directly signed by a 1024-bit root.
It is December 2010 for RapidSSL, as I mentioned in the link.
Instead of guessing, why not check the latest Project Sonar scan data from scans.io? https://scans.io/study/sonar.ssl
Depends on: 1132496
https://control.llnw.com/ was issued during 2014. I think it was a special exception, right?
It is unfortunate that 1024-bit root removal and end of 1024-bit end entity certificates was mixed up. I'd rather see 1024-bit end entity certs issued under a 2048-bir root than a 1024-bit root.
Yuhong, Thank you for your research into this. Your efforts are greatly appreciated.

Rather than spending any more time discussing what should have been, let's focus on the task at hand, which is for Symantec to get their customers migrated off of these roots before the websites and code signing trust bits are turned off in a released version of Firefox. We are currently targeting Firefox 38 for the change, so our Symantec friends have a lot of work to do.
https://wiki.mozilla.org/RapidRelease/Calendar
Yea, fortunately I don't think there are any significant number of these sites, but it is good to remind Symantec of them.
Test builds of a development version of Firefox, which contain the requested change(s), can be found here:
https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/kaie@kuix.de-cb8002df70cc/
I checked that the requested change has been made to the "Equifax Secure CA" and "Equifax Secure Global eBusiness CA-1" roots.

If anyone else want to double-check the change, instructions are here:
https://wiki.mozilla.org/CA:How_to_apply#Testing_Inclusion
services.geotrust.com still uses the old 1024-bit Equifax root.
I ran a pass against both the Pulse and Google CT lists in Kai's build of Fx38 (which has Equifax roots removed). This pass ran against almost 3 million sites, so should be pretty comprehensive.

I'm attaching a text file of sites that a) chain to an Equifax cert and b) will break upon removal. Note that most sites out there today that have these certs are already broken now due to certificate expiration.

* Of almost 3 million sites, 8705 sites chain to these certs
* 1102 sites break uniquely when we remove the Equifax certs
Attachment #8431106 - Attachment is obsolete: true
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: Target Firefox 38 → Websites and Code Signing Trust Bits turned off in Firefox 38
For the record, we are going to currently intend to revert this bug in bug 1155279.

To avoid confusion and allow this bug to continue to track the changes for the old releases, I suggest to file a new bug to get this done again at a later time.
Just to be clear, we only reverted the trust bits for the "Equifax Secure Certificate Authority" root.

I filed Bug #1156844 to track creating a new plan for phasing out the "Equifax Secure Certificate Authority" 1024-bit root.
FYI, the *.intel.com certificates just expired today, along with the Intel External Basic Issuing CA intemediates.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: