Closed Bug 275576 Opened 15 years ago Closed 15 years ago

Add Camerfirma CA certificate to NSS

Categories

(NSS :: Libraries, enhancement, P3)

enhancement

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: hecker, Assigned: nelson)

References

Details

(Whiteboard: [root CA])

Attachments

(3 files, 2 obsolete files)

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
Attached patch certs added to trunk (obsolete) — Splinter Review
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.
Attachment #176443 - Flags: review?(hecker)
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
Attachment #176443 - Attachment is obsolete: true
Attachment #176511 - Flags: review?(julien.pierre.bugs)
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.
Attachment #176443 - Flags: review?(hecker)
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
Whiteboard: [root CA]
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 ago15 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Attachment #180847 - Flags: review?(nelson)
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] [edit])
> 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 dev-tech-crypto@lists.mozilla.org mailing list.
You need to log in before you can comment on or make changes to this bug.