936304 - Remove Entrust.net, GTE CyberTrust, and ValiCert 1024-bit root certificates from NSS

Status: RESOLVED FIXED

(NSS :: CA Certificates Code, task)

Description

[Kathleen Wilson]

As per Bug #881553, please remove the following root certificates from NSS.

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: 99:A6:9B:E6:1A:FE:88:6B:4D:2B:82:00:7C:B8:54:FC:31:7E:15:39

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

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

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

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


Additionally, please turn off the websites and code signing trust bits for the following two NetLock certs.

CN = NetLock Uzleti (Class B) Tanusitvanykiado
OU = Tanusitvanykiadok
O = NetLock Halozatbiztonsagi Kft.
L = Budapest
C = HU
SHA1: 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
OU = Tanusitvanykiadok
O = NetLock Halozatbiztonsagi Kft.
L = Budapest
C = HU
SHA1: E3:92:51:2F:0A:CF:F5:05:DF:F6:DE:06:7F:75:37:E1:65:EA:57:4B

Comment 1

[Kai Engert (:KaiE:)]

Attachment: patch v1

I'll create a test build soon.

Comment 2

[Kai Engert (:KaiE:)]

Attachment: patch v2

This patch is functionally equivalent to v1.

However, this patch v2 is made on top of the changes from bug 942147, therefore making it easier to review that the changes affect the intended certificates.

Comment 3

[Kai Engert (:KaiE:)]

Try build with the patch:
https://tbpl.mozilla.org/?tree=Try&rev=6b8e982121a3

Should be available here in a few hours:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/

(search for 6b8e982121a3).

Can you please test?

Comment 4

[Kathleen Wilson]

Comment on attachment 8336799 [details] [diff] [review]
patch v2

Review of attachment 8336799 [details] [diff] [review]:
-----------------------------------------------------------------

Tested and reviewed the code changes. The changes are as requested. Thanks!

Comment 5

[Kathleen Wilson]

This can go into Firefox 28. Thanks!

Comment 6

[Kathleen Wilson]

Delaying one more release -- to Firefox 29.
https://wiki.mozilla.org/RapidRelease/Calendar

Comment 7

[Kai Engert (:KaiE:)]

Bob, FYI, this is another bug with root CA changes for this round, but Kathleen already reviewed it.

(I'll check this in as soon as the patch in bug 957300 is ready for landing.)

Comment 8

[Kai Engert (:KaiE:)]

https://hg.mozilla.org/projects/nss/rev/1cef53398ecf

Comment 9

[Jesper Kristensen]

Maybe I should file a new bug, but not sure where to put it, so I just comment here: In the current Nightly, I get a SSL error message (sec_error_unknown_issuer) when connecting to various sites under force.com, for example https://c.cs17.visual.force.com . The site works correctly in Release, where it chains up to "GTE CyberTrust Global Root".

Comment 10

[Kathleen Wilson]

(In reply to Jesper Kristensen from comment #9)
> Maybe I should file a new bug, but not sure where to put it, so I just
> comment here: In the current Nightly, I get a SSL error message
> (sec_error_unknown_issuer) when connecting to various sites under force.com,
> for example https://c.cs17.visual.force.com . The site works correctly in
> Release, where it chains up to "GTE CyberTrust Global Root".

I just tried it, and when I browse to that site I find that it uses a recently issued SSL cert that chains to a different (non-1024-bit) root, so I believe the site owner has resolved the problem.

Comment 11

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Kathleen Wilson from comment #10)
> I just tried it, and when I browse to that site I find that it uses a
> recently issued SSL cert that chains to a different (non-1024-bit) root, so
> I believe the site owner has resolved the problem.

Please try in a brand-new profile. I think Gecko's certificate caching is making it work for you because you visited a site that had an intermediate that makes it work.

I think we should have one bug per CA for each compatibility issue that this bug causes, and work with the CA in each bug to resolve it.

Comment 12

[Kathleen Wilson]

(In reply to Brian Smith (:briansmith, was :bsmith; NEEDINFO? for response) from comment #11)
> (In reply to Kathleen Wilson from comment #10)
> > I just tried it, and when I browse to that site I find that it uses a
> > recently issued SSL cert that chains to a different (non-1024-bit) root, so
> > I believe the site owner has resolved the problem.
> 
> Please try in a brand-new profile. I think Gecko's certificate caching is
> making it work for you because you visited a site that had an intermediate
> that makes it work.


Really? So, removing cert8.db is not good enough?


> 
> I think we should have one bug per CA for each compatibility issue that this
> bug causes, and work with the CA in each bug to resolve it.

Yes.

Comment 13

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Kathleen Wilson from comment #12)
> (In reply to Brian Smith (:briansmith, was :bsmith; NEEDINFO? for response)
> from comment #11)
> > (In reply to Kathleen Wilson from comment #10)
> > > I just tried it, and when I browse to that site I find that it uses a
> > > recently issued SSL cert that chains to a different (non-1024-bit) root, so
> > > I believe the site owner has resolved the problem.
> > 
> > Please try in a brand-new profile. I think Gecko's certificate caching is
> > making it work for you because you visited a site that had an intermediate
> > that makes it work.
> 
> Really? So, removing cert8.db is not good enough?

Removing cert8.db should be good enough, assuming you clear the cache (History -> Clear Recent History -> Everything, [x] Cache), shut down the browser, remove the cert8.db file, and then start the browser again.

Comment 14

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Reverted this change for NSS 3.16, based on NSS teleconference discussion. We'll do this for NSS 3.17 after we come up with a plan for dealing with the compatibility issues.

http://hg.mozilla.org/projects/nss/rev/d793d89df060

Comment 15

[Dirkjan Ochtman (:djc)]

Firefox 32 is now. Is this still happening?

Comment 16

[Kathleen Wilson]

Compatibility testing is scheduled to happen this week. Stay tuned.

Comment 17

[Matt Wobensmith [:mwobensmith][:matt:]]

Attachment: final-BROKEN-URLS-936304.txt

This list of 217 sites was obtained by running over 200,000 top SSL-enabled sites against Fx32, compiled without these root certs. It is not - repeat: 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.

Comment 18

[Kathleen Wilson]

Matt, Thank you for doing this testing.

Steven and Bruce, We are targeting to remove the 1024-bit roots listed in this bug in Firefox 32 (https://wiki.mozilla.org/RapidRelease/Calendar). Matt has run a compatibility test to see what would happen when these roots are removed, and found that the attached list of websites will be impacted. Of the sites in the list that I sampled, the SSL certs chained up to either of the following two roots. Please inform these customers of the upcoming change.

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: 99:A6:9B:E6:1A:FE:88:6B:4D:2B:82:00:7C:B8:54:FC:31:7E:15:39

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

Comment 19

[Bruce Morton]

We think that there are limited number of sites which are impacted by the Entrust issuing CAs. We have issued cross-certificates to some third party CAs. They have been informed that the Entrust (1024-bit) root should not be trusted as of 2010 and have been re-issued cross-certificates from our 2048-bit root. Looks like some of those sites may not have been cleaned up over the last 3 years. If their support team cannot reach them in advance, this problem will undoubtedly be corrected shortly after the change.

Thanks for the feedback, we will hope to get this corrected in advance.

Bruce.

Comment 20

[Kathleen Wilson]

A Test Build with these changes has been created as part of Bug #1021967.
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-394c2eeb9793/

I have already checked/tested it, but you are all welcome to check it too.

Comment 21

[Kai Engert (:KaiE:)]

fixed as part of bug 1021967

Comment 22

[Kathleen Wilson]

Discussion about mitigating compatibility issues with this change:
https://groups.google.com/d/msg/mozilla.dev.security.policy/JFGRyr4-F44/sl44ywYCEdYJ

Comment 23

[Kai Engert (:KaiE:)]

This bug was marked as being related to, dependent on bug 957300. I think that was a mistake, because in the commit for bug 957300 I cannot see any action related to the requests in this bug.

I'm therefore removing the dependency.