Closed Bug 275576 Opened 15 years ago Closed 15 years ago
Add Camerfirma CA certificate to NSS
112.77 KB, patch
|Details | Diff | Splinter Review|
7.75 KB, application/x-zip-compressed
1.39 KB, patch
|Details | Diff | Splinter Review|
Per my comments in bug 261778 I'm approving addition of two root CA certificates for Camerfirma: Chambers of Commerce Root CA: http://www.camerfirma.com/mod_web/consultas/certi/Chambers.cer SHA-1 fingerprint: 1B 31 BE 5D A5 ED BC 71 1E FE 83 76 5F 3B 0B 27 25 75 F4 D2 Global Chambersign CA: http://www.camerfirma.com/certs/ROOT-CHAMBERSIGN.crt SHA-1 fingerprint: 33 9B 6B 14 50 24 9B 55 7A 01 87 72 84 D9 E0 2F C3 D2 D8 E9 Both certificates should be marked as trusted for all purposes.
Priority: -- → P3
Target Milestone: --- → 3.10
Version: unspecified → 3.9
This patch adds the certs requested for this bug (camerafirma) and also for bug 280744 (the NetLock CA certs) to the trunk for NSS 3.10. With this patch applied, the following new nicknames, certs and trust flags appear in nssckbi: Camerfirma Chambers of Commerce Root C,C,C Camerfirma Global Chambersign C,C,C NetLock Notary (class A) Root C,C,C NetLock Business (class B) Root C,C,C NetLock Express (class C) Root C,C,C Frank, please let me know if those nicknames seem OK. I didn't add xramp because I cannot resolve any DNS addresses in their xrampsecurity.com domain.
This zip file contains the raw certs that corrrespond to the above patch, and the simple shell script that added them to the list.
(In reply to comment #1) > Camerfirma Chambers of Commerce Root C,C,C OK. > Camerfirma Global Chambersign C,C,C OK. > NetLock Notary (class A) Root C,C,C > NetLock Business (class B) Root C,C,C > NetLock Express (class C) Root C,C,C I suggest capitalizing the word "class" in the above nicknames.
I got interrupted while writing my previous comment, and forgot to add: Thanks very much for taking the time to do this patch; I know you're very bogged down with other stuff.
This patch also includes the XRamp CA cert (see bug 274723). The list now appears as: Camerfirma Chambers of Commerce Root C,C,C Camerfirma Global Chambersign C,C,C NetLock Notary (Class A) Root C,C,C NetLock Business (Class B) Root C,C,C NetLock Express (Class C) Root C,C,C XRamp Global CA Root C,C,C
This zip file contains the raw DER certs being added, and includes a small shell script that runs addbuiltin to add them. This facilitates adding these certs to other branches, which the maintainers of other braches may wish to do.
Attachment #176444 - Attachment is obsolete: true
Comment on attachment 176443 [details] [diff] [review] certs added to trunk Removed review request from obsolete patch.
Comment on attachment 176511 [details] [diff] [review] revised patch includes XRamp CA too Looks OK.
Attachment #176511 - Flags: review?(julien.pierre.bugs) → review+
Thanks for the review. Checking in certdata.c; new revision: 1.33; previous revision: 1.32 Checking in certdata.txt; new revision: 1.34; previous revision: 1.33
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Verified with NSS 3.10 Beta 3 that Camerfirma Chamber of Commerce Root CA and Global Chambersign Root CA are in the "Builtin Object Token" with the following trust settings: This certificate can identify web sites. This certificate can identify mail users. This certificate can identify software makers. Mozilla/Firefox trunk nightly builds on 2005-04-13 or later will have these root CA certs. The upcoming milestone releases are Mozilla 1.8 Beta 2 and Firefox/Thunderbird 1.1 Alpha.
Status: RESOLVED → VERIFIED
I just found that the Chambers of Commerce Root in NSS has a different SHA-1 fingerprint from the one Frank wrote in comment 0. So I'm reopening this bug for investigation. The Chambers of Commerce Root in NSS has this SHA-1 fingerprint: 6E 3A 55 A4 19 0C 19 5C 93 84 3C C0 DB 72 2E 31 30 61 F0 B1
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Before checking in any of the recent new CA certs, I built a new nssckbi.dll and put it on my personal web site, and invited users to download it and test it. I sent email to the CA themselves asking them to test it and make sure it was right. I received at lease a few positive replies but some CAs did not reply. So, If I actually managed to get the wrong cert, it says that the CAs didn't test the certs. :( I encourage you to compare the certs I checked in with those offered by the CAs on the URLs given on Frank's web page. If they are the same, then the question is why does the Fingerprint listed by Frank differ from the one on the cert from the CAs site.
Nelson, The Chambers of Commerce Root you added is the same as the one at the URL in comment 0 (the same as the URL on Frank's web page).
Marked the bug fixed again. Nelson added the correct cert and the correct SHA-1 fingerprint is 6E 3A 55 A4 19 0C 19 5C 93 84 3C C0 DB 72 2E 31 30 61 F0 B1
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
Comment on attachment 180847 [details] [diff] [review] Add "Root" to the nickname for the "Global Chambersign" root Should be fine.
Attachment #180847 - Flags: review?(nelson) → review+
Comment on attachment 180847 [details] [diff] [review] Add "Root" to the nickname for the "Global Chambersign" root Patch checked in on the NSS trunk for NSS 3.10. Checking in certdata.txt; /cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.txt,v <-- certdata.txt new revision: 1.37; previous revision: 1.36 done Checking in certdata.c; /cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.c,v <-- certdata.c new revision: 1.36; previous revision: 1.35 done
(In reply to comment #17) > (From update of attachment 180847 [details] [diff] [review] ) > Patch checked in on the NSS trunk for NSS 3.10. > Checking in certdata.txt; > /cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.txt,v <-- > certdata.txt > new revision: 1.37; previous revision: 1.36 > done > Checking in certdata.c; > /cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.c,v <-- certdata.c > new revision: 1.36; previous revision: 1.35 > done I realized that AC Camerfirma intermediate CAs are not included in the Mozilla CA store, this is a problem for us since one of these CAs issue HTTPS Server Certificates and therefore an CA not trusted error is shown by the browser when someone try to access to a HTTPS website certified by AC Camerfirma.
NSS does not pre-load or otherwise store intermediate CA certificates because the SSL/TLS standards dictate that HTTPS servers should send a certificate chain (including intermediate CA certificates) to browsers. The web site reporting the problem is most likely not configured correctly. The web site should install the Camerfirma intermediate CA certificate along with its own certificate, and send both of them. (Instructions on how to do this vary depending on the type of server.) The reason you do not see this problem with IE is because Windows/IE caches intermediate CA certificates, and (contrary to the standards) does not require a full cert chain be sent. If you have additional questions about this matter please post to the mozilla.dev.tech.crypto newsgroup or email@example.com mailing list.
You need to log in before you can comment on or make changes to this bug.