Closed Bug 424169 Opened 16 years ago Closed 16 years ago

Add GeoTrust Primary Certification Authority root to NSS

Categories

(NSS :: Libraries, enhancement)

Product:
NSS
Component:
Libraries
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
3.11.10

People

(Reporter: hecker, Assigned: KaiE)

References

Details

Attachments

(1 file)

GeoTrust Primary Certification Authority certificate
1.24 KB, application/x-x509-ca-cert
Details 
This bug requests inclusion in the NSS root certificate store of the following
root CA certificate, owned by GeoTrust:

1) Friendly name: "GeoTrust Primary Certification Authority"
   SHA-1 fingerprint:
32:3C:11:8E:1B:F7:B8:B6:52:54:E2:E2:10:0D:D6:02:90:37:F0:96
   Trust flags: Web sites
   URL:
https://bugzilla.mozilla.org/attachment.cgi?id=306731

The GeoTrust Primary Certification Authority has been assessed in accordance with the Mozilla project guidelines, and the certificate approved for inclusion per bug 407168.

The remaining 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.
Blocks: 424171
Depends on: 425469
Dear GeoTrust representatives, you have not yet confirmed the information listed in this bug is correct.

I went ahead and included your certificate in a test build anyway.
Please read bug 425469 comment 3 to find the binary roots module for testing and follow Frank's requests given in this tracking bug.

Adding your roots to Mozilla/NSS is blocked pending your confirmation that everything is correct.

Please do not forget to verify the trust flags are correct.

For item 1 the information in the bug is correct and the cert attached is correct. I am still waiting on confirmation internally regarding the OS we will use to the verification and who will perform step 2.
We have tested with the test build, and chaining doesn't seem to work properly. When we use FF to visit a site with an EV cert (www.geotrust.com), the server returns this chain: EE->intermediate->cross cert. But FF shows the chain as
EE->intermediate->cross cert->old root, which is not the expected behavior. We expected it to chain up to the new root.

Also, we need all three trust flags set, but only "web sites" is set.
(In reply to comment #4)
> Also, we need all three trust flags set, but only "web sites" is set.

My comments in bug 422918 apply here as well.


Should we go ahead and start by adding the root now, with trust flag SSL only?

We could fix the trust flags at a later time.

Rick,  In reply to comment 4, 
I gather that you expect that the cert chain shown in FF's Certificate Viewer 
dialog will be the EV cert chain, once the site is shown to be an EV site.
While that is indeed a reasonable expectation, that's now how FF works now.

FF does two separate cert validations, the first one ignoring EV and policy 
extensions (merely asking: is this a valid TLS server cert?) and a second 
one paying attention to EV and policy extensions (asking: is this a valid 
EV TLS server cert?).

Those two operations are done with different sets of trust anchors (the EV 
trust anchors being a subset of the full set of TLS trust anchors), and may
very well validate two different cert chains when cross certified CAs are 
involved.  

The cert chain shown by the Cert Viewer is the result of the first validation,
not the second validation.  One cannot correctly infer anything about the 
cert chain that is validated in the second (EV) validation from the chain
that is validated in the first validation.  One cannot determine whether 
the EV validation was done with the expected certification path by examining 
the certification path used in the firsrt (non-EV) validation.  

Essentially, all you can do, at this point, is to ascertain that the browser
does or does not properly show the EV status of a given server.  I suggest
that you test it by visiting numerous different servers, some of which 
should show as EV, and other of which should not.  If it gets the expected
results in all test cases, then it should be acceptable.  

BTW, I think it is likely that, sometime after the release of FF 3.0.0.0,
perhaps within the next year (no promises), that FF3 will change to show
the EV validation path in the Certificate Viewer dialog for EV sites.  
But today, it does not.
Correction: I wrote "that's now how FF works".  I meant that's NOT how FF works.
I make that typing mistake all the time. Spell checker doesn't catch it. Sorry.
Frank, I think I understand your description of the two chain checks. Thanks for giving me some insight into how it works. I'm curious, though, as to why the chain looked different for the GeoTrust EV root. Why didn't FF2 chain up to the GeoTrust EV root, a shorter chain than the one up to the Equifax root? For the VeriSign and Thawte EV roots, FF2 chained up to the new EV roots, not the legacy roots.

You say "Essentially, all you can do, at this point, is to ascertain that the browser does or does not properly show the EV status of a given server." But I can't really do that, because I'm using FF2 (as per the instructions in bug 425469 comment 3). I was trying to infer that FF would see this as a valid EV cert by viewing the chain. All I can do at this point is ascertain that the browser sees the server's cert as trusted.
Rick,

bug 425469 comment 3  and bug 425469 comment 6 both contain this description 
of their respective attachments:
   "Zip file containing a nssckbi.dll compatible with Firefox 2."

IINM, the point of that comment is that the file can be tested both with FF2
and with FF3.  The intent (IIRC) is to add the new root certs to both versions
of FF, but (of course) the EV testing can only be done with FF3.  But I forgot
about the intent to retrofit FF2 when I wrote comment 7.  I've got EV on the 
brain. :/

> Why didn't FF2 chain up to the GeoTrust EV root, a shorter chain than the 
> one up to the Equifax root?

The algorithm used in FF2 (which is also the algorithm used for the non-EV
validation in FF3) pays no attention to path length (except to enforce path 
length constraints) when choosing among paths while constructing a chain to 
validate.  It attempts to build a path from leaf to (some) trusted root.  
When it goes to search for a CA cert and finds multiple certs for a given 
CA name, all of which are acceptable based on the constraints imposed by the 
subordinate cert (i.e., all are in their validity periods, and all have the 
same subject key ID, if the subordinate specifies an authority key ID), it 
chooses the "newest" cert from among those.  The determination of "newest" 
is based on the notBefore date, which is presumed to be the date of issuance. 
If multiple certs have the exact same notBefore date, so that there is a tie 
for "newest", it chooses the one with the latest (most future) notAfter date.

So, if you have a CA for which multiple certs exist, perhaps one being a self-signed root and another being subordinate to another CA, and all are
acceptable (validity periods, key IDs, etc.) then it will always pick the
"newest" from among them.  

Nelson, I think I've misunderstood what you wanted us to do. When I read bug 425469 comment 3, it seemed to me that all I could do was test the dll with version 2. For me to test with version 3, I would have to obtain a version of 3 that contains the roots in question. I don't think you expect me to build this myself, so I assume you expect me to download it from somewhere. But I would hope that someone could just point me to it. Am I missing something?
Rick: You can certainly download a copy of Firefox 3 beta 5 from

http://www.mozilla.com/en-US/firefox/all-beta.html

and then take the DLL and use it to replace the existing DLL of the same name in Firefox 3 b5. This will test the ability of Firefox 3 to see the new root, period. However it will not test the ability of Firefox 3 to see EV certs issued from the new root. That will require a new build of Firefox 3 with the appropriate EV OID(s) added. (Since that information is not stored in NSS, but separately.)

I think the point of the present exercise is simply to confirm that the new root shows up properly as a non-EV root. Then this bug can be resolved FIXED and Kai can proceed to bug 424171, which involves enabling EV for the root.



The test binary is compatible with Firefox 2.

I can not guarantee that it will work with Firefox 3, because different compiler and runtime library versions are used.

You can not use the binaries to test EV.

The test binaries do not contain anything that would enable Firefox to accept your roots for EV.

Blessing roots for EV happens in separate code, that is to be added with bug 425518.

This bug is strictly about adding the raw certs to NSS, without any information about EV.

I agree with Frank's comment 12, with the exception I make in comment 13.

If you want to test EV now, without waiting until we have completed both bug 425469 and bug 425518, then your only chance is to produce a build yourself, where you have added the most recent patches from both bugs manually.

But I offer to just do a quick test with my local test build, where I have done all that.

I take my offer from comment 16 back.

Rick, at this point I am unable to do any real EV testing with the EV site, because the Geotrust OCSP responder is broken.

The problem is desribed in bug 425538.

Rick, the purpose of this bug is to confirm that the root works correctly with classic SSL, DV (not EV).

Because of bug 425538 and bug 425518 we can't test EV yet.

But resolving this bug is a requirement, a dependency before we can proceed.

I propose we get this bug done, add the root, and work on correct EV behavior as a separate task.

I think you have confirmed in this bug that all information has been added correctly as approved (expect the missing email/object signing trust flags which will be dealt with later).

So, I reread this bug, and see that you have not yet confirmed it's correct, because the chaining is wrong.

I propose you do the following to confirm that Firefox 2 is correctly able to chain to your new root:

Go to certificate manager and find your old roots. Click "edit" and remove the trust flags for your old root. Then restart Firefox and connect to your test site again.

This time you should see that it chains up to your new root, proving that the root can be correctly used to verify your server for classic SSL / DV.

Kai, removed the trust flags from the old root, Equifax Secure CA, and restarted. I got a warning saying it could not identify www.geotrust.com as a trusted server. (I got the same error when I tried to file this comment, because *.mozilla.org's cert is signed under the Equifax root :^)

So I think that means that something is wrong, and FF cannot build a chain from the end entity to the new root. I'm going to look at all the certs in the chain in detail to see if I can tell what's wrong.
Sorry, my comment 19 was wrong.
I take it back.

Thanks a lot to Nelson for describing the problem.
It's not possible to use Firefox 2 to test the chaining to the new root, because it can not deal with multiple possible validation paths when looking for the root.

You can not test it with Firefox 3 either, because Firefox 3 continues to use the same logic for basic cert verification, and it uses the old logic to find the chain that will be reported in the user interface.

And I can not help testing it locally either, because your OCSP server is broken (or appears to be broken, bug 425538).

There is currently no simple way to correctly test the chaining.

Nelson was smart enough to think of a test scenario that might work, but it would require you to set up a test server that omits one of the cross certs.


But I would like to propose, let's simplify.
The purpose of this bug is to get your root added.


Please confirm that the root certificate has been added correctly, by looking at the user interface when you use certificate manager to view your cert.

Please confirm that we have enabled your cert as trusted for SSL, by looking at the trust flag shown in certificate manager.


If you approve the above by tomorrow noon US eastern time, there is a chance that you will get EV treatment in Firefox 3 as soon as the OCSP server issue from bug 425538 is addressed.


It will also give you the chance to test the Firefox 3 Release Candidate, and it would be great if you could do that as soon as its gets released.
Should you find out that your root got added incorrectly, then we'll have a chance of fixing it.


If you want to expedite things, you could try to have your experts look into the OCSP server issue of bug 425538 as soon as possible. As soon as this gets fixed, I could run a test locally and find out whether we correctly show EV for your test site.


(If you choose not to confirm that the correct root got added, then this root will not be added in time for the initial release of Firefox 3.)

(In reply to comment #20)
> Kai, removed the trust flags from the old root, Equifax Secure CA, and
> restarted. I got a warning saying it could not identify www.geotrust.com as a
> trusted server. (I got the same error when I tried to file this comment,
> because *.mozilla.org's cert is signed under the Equifax root :^)
> 
> So I think that means that something is wrong, and FF cannot build a chain from
> the end entity to the new root. I'm going to look at all the certs in the chain
> in detail to see if I can tell what's wrong.


I apologize for having suggested an incorrect test.


(In reply to comment #21)
> Nelson was smart enough to think of a test scenario that might work, but it
> would require you to set up a test server that omits one of the cross certs.

In order to test that your new root can be found as a valid root, you could set up a test server that does not send out cross certificates, but only sends out the server cert and intermediate certs that build a chain to your new root.

Then you could use a fresh profile with Firefox (which does not have any intermediates or cross certs imported) and visit that special test site. Then you should see that it correctly chains up to your new root.

Thanks a lot to Nelson for his proposal, and I hope I have correctly described it.
Kai, no problem; it didn't take much time.

The OCSP Server issue of bug 425538 is actively being worked on; I have an ETA
of Monday for it to be fixed.

I confirm that the root certificate has been added correctly, by looking
at the user interface when I use certificate manager to view my cert.

I confirm that you have enabled this cert as trusted for SSL, by looking at
the trust flag shown in certificate manager.
Thank you Rick.
We believe the OCSP issue has been resolved (I verified it; it works for me now) so the work on this bug can proceed.
This root was added to NSS for version 3.12 with a checkin noted in bug 425469.
Marking fixed.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Please see bug 425538 comment 27.

According to my tests, when executing a policy verification using NSS' new verification engine, we indeed find the expected chain to the new root.

(Although the view certificate user interface still reports the chain to a different root, which is expected, too. Yes, this is a bit confusing, we'll hope to be able to make this consistent at a later time.)

As I noted in comment 27 in this bug, the root has been added to NSS. (FYI, our next steps are to checkin bug 426681 and bug 425518, which we will do as soon as possible.)
Target Milestone: --- → 3.12
Target Milestone: 3.12 → 3.11.10
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: