936105 - Remove or turn off trust bits for Symantec 1024-bit root certs

Status: RESOLVED FIXED

(CA Program :: CA Certificate Root Program, task)

Description

[Kathleen Wilson]

This bug tracks removing or turning off trust bits for Symantec's 1024-bit root certs that are included in NSS and have the Websites and/or Code Signing trust bits turned on by default.

According to https://wiki.mozilla.org/CA:MD5and1024
December 31, 2013 – Soon after this date, Mozilla will disable the SSL and Code Signing trust bits for root certificates with RSA key sizes smaller than 2048 bits. If those root certificates are no longer needed for S/MIME, then Mozilla will remove them from NSS.

Here are the relevant root certificates:

> Equifax	
> Equifax Secure Certificate Authority	
> Equifax Secure CA	
> 1998 Aug 22	
> 2018 Aug 22	
> SHA-1

All three trust bits currently enabled. 


> Equifax Secure Inc.		
> Equifax Secure Global eBusiness CA-1	
> 1999 Jun 21	
> 2020 Jun 21	
> MD5

All three trust bits currently enabled. 


> Equifax Secure Inc.		
> Equifax Secure eBusiness CA-1	
> 1999 Jun 21	
> 2020 Jun 21	
> MD5

All three trust bits currently enabled. 


> Thawte Consulting cc	
> Certification Services Division	
> Thawte Server CA	
> 1996 Aug 01	
> 2020 Dec 31	
> MD5

The Websites and Code Signing trust bits are currently enabled (email trust bit not currently enabled.)


> Thawte Consulting cc	
> Certification Services Division	
> Thawte Premium Server CA	
> 1996 Aug 01	
> 2020 Dec 31	
> MD5

The Websites and Code Signing trust bits are currently enabled (email trust bit not currently enabled.)


> VeriSign, Inc.	
> Class 3 Public Primary Certification Authority	
> VeriSign Class 3 Public PCA	
> 1996 Jan 29	
> 2028 Aug 01	
> MD2

All three trust bits currently enabled.


> VeriSign, Inc.	
> VeriSign Trust Network	
> VeriSign Class 2 Public PCA – G2	
> 1998 May 18	
> 2028 Aug 01	
> SHA-1

Email and code signing trust bits currently enabled. (Websites trust bit not currently enabled)


> VeriSign, Inc.	
> VeriSign Trust Network	
> VeriSign Class 3 Public PCA – G2	
> 1998 May 18	
> 2028 Aug 01	
> SHA-1

All three trust bits currently enabled. 


> VeriSign, Inc.
> Class 3 Public Primary Certification Authority	
> VeriSign Class 3 Public PCA	
> 1996 Jan 29	
> 2028 Aug 02	
> SHA-1

All three trust bits currently enabled.

Comment 1

[Kathleen Wilson]

Rick, Please update this bug as you determine dates for when each of these root certificates may either be removed or have the trust bits modified.

As you know, our goal is to do this as soon as possible in 2014. However, I understand that there may be different dates for different root certs, and I prefer to take action on root certificates as soon as you are ready (and not wait for all of them to be done all at the same time). In other words, let's do this in phases.

Comment 2

[Kathleen Wilson]

Update from Symantec:

Symantec is actively working to move certs away from these 1024-bit roots, but there are a lot of long-lived certs that were issued before October, 2010, when the mandate to move from 1024-bit certs was officially communicated to CAs (https://wiki.mozilla.org/CA:Communications#October_11.2C_2010). At that time, 5-year certs were being issued, so many of those certs remain valid until 2015. For those certs and their respective roots, the following caveat applies. 

https://wiki.mozilla.org/CA:MD5and1024
"Caveats to proposed dates: ...
    There were some long-lived certs that were issued before this policy was put in place; as long as caveat #1 and #2 have not happened and there is no evidence of breaches regarding these certs, these certs may be allowed to expire before the root is removed."

Having said that, Symantec is working diligently to move off of these 1024-bit root certificates as quickly as possible. They are not just waiting until all the long-lived certs expire, but are actively contacting customers to transition them to new certs.

It is also worth noting that most of the more recent certs chaining up to these roots are 2048-bit certs themselves, and also chain up to the corresponding 2048-bit roots (via cross-signing). For those certs, Firefox is only checking the validation path chaining up to the 2048-bit roots, because currently cross-signing depends on the notAfter/notBefore dates of the certificates in question (which one was issued later).

Comment 3

[Nicolas Melay]

I confirm that real customers are still using these roots today.
We were, a few months ago, until I incidentally took notice of this rather unexpected early retirement project.

As has been said, certificates signed with Equifax Secure CA were still sold in 2009 (2010?) with 5 years of validity, most notably through the RapidSSL program.
This specific root, Equifax Secure CA, is known/supported by very old browsers and devices from the last century (with no support for chained certificates and a limited root certificates catalog).
This was considered a valuable feature a few years back, and marketed as such.

However, the affected customers are not just large companies.
RapidSSL targets the *value* segment, and is sold through a large number of resellers worldwide, so getting back to those customers might prove to be a real challenge.

To this date, we have not been contacted by Symantec, GeoTrust or our certificate reseller about this root expiration issue (though we did renew it on December 1st, 2013).

Note that RapidSSL certificates can be reissued with a 2048-bit root on demand from their website, whatever the reseller, as long as the original certificate is still valid.

Comment 4

[David E. Ross]

(In reply to Nicolas Melay from comment #3)
> However, the affected customers are not just large companies.
> RapidSSL targets the *value* segment, and is sold through a large number of
> resellers worldwide, so getting back to those customers might prove to be a
> real challenge.

Does this mean subscriber certificates were signed without Symantec having knowledge of who the subscribers are?  Does this mean Symantec allowed its root or intermediate certificates to be used in the creation of subscriber certificate without any rigorous oversight of the process?

Comment 5

[Nicolas Melay]

OK, had a talk with my reseller about this issue yesterday, and it appears they *did* attempt to contact us, but used a wrong e-mail address.
Since I subsequently got aware of it and resolved it all by myself, they did not try to reach to us any further.
He assured me that the issue has been fully handled on their side, and that each of their customers was now using certificates signed by 2048-bit roots.
That's just one reseller in one SSL certificates program though.

Comment 6

[Rashmi Tabada]

Hi Kathleen,

Is there a specific date in september when the next set of 1024-bit roots will be untrusted?
Please let me know.

Thanks,
Rashmi

Comment 7

[Kathleen Wilson]

(In reply to Rashmi Tabada from comment #6)
> Is there a specific date in september when the next set of 1024-bit roots
> will be untrusted?

Please see Bug #986014 for the answer to your question.

Comment 8

[Gervase Markham [:gerv]]

Does this bug itself cover any root removals, or are they all covered by the dependent bugs?

Gerv

Comment 9

[Kathleen Wilson]

(In reply to Gervase Markham [:gerv] from comment #8)
> Does this bug itself cover any root removals, or are they all covered by the
> dependent bugs?

All of the 1024-bit root changes for this bug are covered by the dependent bugs. So, should we close this bug as a duplicate?