1.15 KB, application/x-x509-ca-cert
8.78 KB, patch
Nelson Bolyard (seldom reads bugmail): review+
Robert Relyea: superreview+
|Details | Diff | Splinter Review|
272.00 KB, application/octet-stream
48.29 KB, image/jpeg
48.31 KB, image/gif
This bug requests inclusion in the NSS root certificate store of the following certificate(s), owned by Entrust: 1) Friendly name: "Entrust Root Certification Authority" SHA1 Fingerprint: B3:1E:B1:B7:40:E3:6C:84:02:DA:DC:37:D4:4D:F5:D4:67:49:52:F9 Trust flags: Websites The certificate(s) themselves will be attached momentarily. This CA has been assessed in accordance with the Mozilla project guidelines, and the certificate(s) approved for inclusion in bug 382352. The steps are as follows: 1) A representative of the CA must confirm that all the data in this bug is correct, and that the correct certificate(s) have been attached. They must also specify what OS they would like to use to perform the verification below. 2) A Mozilla representative creates a test build of NSS with the new certificate(s), and attaches nssckbi.dll to this bug. A representative of the CA must download this, drop it into a copy of Firefox and/or Thunderbird on the OS in question and confirm (by adding a comment here) that the certificate(s) have been correctly imported and that websites work correctly. 3) The Mozilla representative checks the certificate(s) into the NSS store, and marks the bug RESOLVED FIXED. 4) At some time after that, various Mozilla products will move to using a version of NSS which contains the certificate(s). This process is mostly under the control of the release drivers for those products. Gerv
Bruce: the next action here is yours (see above). Gerv
Entrust has confirmed that the correct root cert is attached to this bug report. Friendly name: "Entrust Root Certification Authority" SHA1 Fingerprint: B3:1E:B1:B7:40:E3:6C:84:02:DA:DC:37:D4:4D:F5:D4:67:49:52:F9
O/S to use is Windows XP
Gerv: the next action is item 2 above. Is someone from Mozilla creating the test build? Thanks, Bruce.
It's my job to do a test build. I haven't done so yet, because I had the hope I could do a single build for multiple cert requests. I'll do it now.
Created attachment 287855 [details] [diff] [review] Patch v1 This is the patch I'm using to create the binary test dll, cert was added with the following folland: addbuiltin -n "Entrust Root Certification Authority" -t C,, < ~/moz/nss/311/entrust.der >> certdata.txt
Created attachment 287876 [details] nssckbi.dll for testing purposes nssckbi.dll for testing purposes Please test with a Windows build of Firefox 2.0.0.x.
I downloaded a the latest version of Firefox 2.0.9 on a clean Windows XP SP1 system. I replaced the nssckbi.dll with the new file from Kai's attachment. The root does not show when I view the cert store from Firefox.
Comment on attachment 287876 [details] nssckbi.dll for testing purposes Sorry, my mistake, I attached the wrong file :-/
Created attachment 288701 [details] better... nssckbi.dll for testing purposes file size: 278528 sha1sum: 6fa4139cf6a1b7ceea22c660dfcbe2df6c9775dd Can you please try again?
Created attachment 288706 [details] new root viewed through Firefox The root is there now. I've added a screen shot too.
Also, confirmed that the thumbprint matches
After testing to see the certification path in firefox, it appears that the test fails. The path should branch up to this root ("Entrust Root Certification Authority") and stop there, however it seems to be going to our other 1024 root. Even if I remove the 1024 root (expiry 2019), I get a trust alert.
Can you please give more details? Do you have a test case? Can you attach the cert you are trying to verify? Or even better, is there a test server to connect to?
Created attachment 288724 [details] cert path incorrect Attached is the incorrect cert path. You can test and view this by hitting https://buy.entrust.net with Firefox using the new nssckbi.dll The path should actually be chained back to the correct root, but it's taking the longer path. There should only be three certificates in the path. The parent which is the new root added, then the L1A chain and then the cert issued to the site itself.
The 4-cert chain shown by Firefox is not incorrect. It is merely not the one that the CA prefers. But this chain, which uses the cross-certified intermediate CA cert, shown in the above image as "Entrust Root Certificate Authority", which chains up to "Entrust.net Secure Server Certification Authority", was created by Entrust, and exists PRECISELY so that servers with the certs from the new hierarchy can correctly chain up to the older root. The version of Firefox with which the test was done displays cert chains constructed by code that does not consider cert policies. There is not yet any version available that does consider cert policies for this display. However it appears to me that, even if it did consider policies, the chain could still legitimately go up to the old root, because the cross cert explicitly allows it! Further work on the issue of cert chain displays depends on a resolution to bug 403691.
Rob, would you like to have the certificate added as is, independent of any discussions about chaining functionality?
Please add the certificate. That makes sense, but it also makes sense for the browser to use the shortest path when possible as it's more practical.
Comment on attachment 287855 [details] [diff] [review] Patch v1 I apologize for having missed this for a while. Requesting review to get this into NSS 3.12 Requesting second review, because we attempt to keep NSS 3.11.x branch in synch wrt root certs.
As part of my review, I'm trying to determine that this bug's patch installs the correct/intended cert. In comment 0, Gerv says this cert was approved in bug 382352. But bug 416544 appears to be requesting this same cert. Should I be concerned?
Comment on attachment 287855 [details] [diff] [review] Patch v1 This patch does appear to contain the correct contents to add the cert requested in bug 382352.
checked in. Checking in certdata.c; /cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.c,v <-- certdata.c new revision: 1.47; previous revision: 1.46 done Checking in certdata.txt; /cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.txt,v <-- certdata.txt new revision: 1.46; previous revision: 1.45 done
(In reply to comment #21) Nelson, this bug request adding the cert to NSS. The other bug is about enabling certs for EV.
Comment on attachment 287855 [details] [diff] [review] Patch v1 r+ with comments... It appears the original request was for SSL, email and code signing, but only SSL was approved? bob
Bob, comment 0 of this bug tells us (NSS team members) that the cert was approved only for SSL. So, if this cert was given trust only for SSL, then NSS (and Kai) did what was requested of it/him. If there is some doubt that comment 0 requested the right trust flags, that comment should probably go into the mozilla.org CA-Certificates bug that led to this NSS bug.
I agree with Nelson's latest comment. At this point we've been requested to technically enable the root for SSL, and that's what we did. Yes, if further trust flags shall be added, Frank must approve that and request that we add more trust. Thanks for the second review. I plan to check in both 425469 and this bug 387892 at the same time into the stable 3.11 branch in the near future.
I've checked in the patches for both bug 425469 and bug 387892 to the NSS 3.11 stable branch, and at the same time I incremented the nssckbi.h version number to 1.66 Marking fixed.
cvs version numbers for branch commit: Checking in certdata.c; /cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.c,v <-- certdata.c new revision: 184.108.40.206; previous revision: 220.127.116.11 done Checking in certdata.txt; /cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.txt,v <-- certdata.txt new revision: 18.104.22.168; previous revision: 22.214.171.124 done Checking in nssckbi.h; /cvsroot/mozilla/security/nss/lib/ckfw/builtins/nssckbi.h,v <-- nssckbi.h new revision: 126.96.36.199; previous revision: 188.8.131.52 done
Changing target milestone to 3.11.10 (not yet released).