Closed Bug 936304 Opened 6 years ago Closed 5 years ago

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

Categories

(NSS :: CA Certificates Code, task)

task
Not set

Tracking

(Not tracked)

RESOLVED FIXED
3.16.3

People

(Reporter: kwilson, Assigned: KaiE)

References

Details

(Whiteboard: Target Firefox 32)

Attachments

(2 files, 1 obsolete file)

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 = info@valicert.com
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 = info@valicert.com
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 = info@valicert.com
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
Attached patch patch v1 (obsolete) — Splinter Review
I'll create a test build soon.
Assignee: nobody → kaie
Attached patch patch v2Splinter Review
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.
Attachment #8335603 - Attachment is obsolete: true
Attachment #8336799 - Flags: review?(kwilson)
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 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!
Attachment #8336799 - Flags: review?(kwilson) → review+
Whiteboard: [do not yet checkin, delay until Firefox 29?]
This can go into Firefox 28. Thanks!
Whiteboard: [do not yet checkin, delay until Firefox 29?] → [do not yet checkin, delay until Firefox 28]
Delaying one more release -- to Firefox 29.
https://wiki.mozilla.org/RapidRelease/Calendar
Whiteboard: [do not yet checkin, delay until Firefox 28] → [do not yet checkin, delay until Firefox 29]
Whiteboard: [do not yet checkin, delay until Firefox 29]
Target Milestone: --- → 3.15.5
Keywords: checkin-needed
Depends on: 957300
Target Milestone: 3.15.5 → 3.16
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.)
https://hg.mozilla.org/projects/nss/rev/1cef53398ecf
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Keywords: checkin-needed
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".
(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.
(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.
(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.
(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.
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
Status: RESOLVED → REOPENED
Depends on: 973592, 974500, 974262
Resolution: FIXED → ---
Target Milestone: 3.16 → 3.16.1
Whiteboard: Target Firefox 32
Firefox 32 is now. Is this still happening?
Compatibility testing is scheduled to happen this week. Stay tuned.
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.
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
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.
Blocks: 1021967
No longer blocks: 1021967
Depends on: 1021967
A Test Build with these changes has been created as part of Bug #1021967.
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/kaie@kuix.de-394c2eeb9793/

I have already checked/tested it, but you are all welcome to check it too.
fixed as part of bug 1021967
Status: REOPENED → RESOLVED
Closed: 6 years ago5 years ago
Resolution: --- → FIXED
Target Milestone: 3.16.1 → 3.16.3
Discussion about mitigating compatibility issues with this change:
https://groups.google.com/d/msg/mozilla.dev.security.policy/JFGRyr4-F44/sl44ywYCEdYJ
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.
No longer depends on: 957300
You need to log in before you can comment on or make changes to this bug.