493258 - Add Cybertrust Global Root certificate to NSS

Status: RESOLVED FIXED

(NSS :: CA Certificates Code, task, P2)

Description

[Kathleen Wilson]

This bug requests inclusion in the NSS root certificate store of the following
certificate, owned by Verizon.

Friendly name: Cybertrust Global Root
Certificate location: 
http://cacert.omniroot.com/ct_root_ss.crt
SHA1 Fingerprint: 
5f:43:e5:b1:bf:f8:78:8c:ac:1c:c7:ca:4a:9a:c6:22:2b:cc:34:c6
Trust flags: Websites 
Test URL: 
https://secure.ichotelsgroup.com/

This CA has been assessed in accordance with the Mozilla project guidelines, and the root certificate have been approved for inclusion in bug 430700.

The next 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. This process is mostly under the
control of the release drivers for those products.

Comment 1

[Kathleen Wilson]

Steven, Please see step #1 above.

Comment 2

[Steven Medin]

Bug is correct, referenced location is correct.

Windows XP for the test, please.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

Kathleen, when filing these NSS bugs, please attach the actual cert(s) to
the bugs, rather than merely providing a URL for them.  We've actually had
problems in the past where the cert at a URL changed after it was entered 
into a bug like this, leading to great confusion about whether the correct
cert had been entered into NSS.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Attachment: The DER cert

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

I have attached a Windows .DLL file to bug 493660.  I believe it contains
the added roots requested in this bug, with the requested (or changed) trust
flags, as requested in comment 0 of this bug.  

Please download that attachment from 
https://bugzilla.mozilla.org/attachment.cgi?id=378202
Check it for viruses, and then follow the instructions given in 
https://bugzilla.mozilla.org/show_bug.cgi?id=493660#c2 
to test it out.  Please report back HERE, in THIS bug, whether it contains
the right cert, by the right name, with the right trust flags.

Comment 6

[Steven Medin]

Nelson, since I see 493259 for the EV patch, I'm limiting the scope on this test to trust only because I don't currently see EV UI.  I can confirm proper termination at the CT Global Root, the subject of this bug, at the test URL above.  I confirm proper trust flags and naming.

What slowed me down a bit at first is I've accessed our customers' sites in Firefox many times prior to installing the DLL so the cross-certificate of the CT Global Root to the GTE CyberTrust Global Root was present as a software security device in the GTE block and the DLL added it as a builtin object token in the Cybertrust block.  The result was that the chain relied on and preferred the cross-certificate.

I'm a bit surprised that a dynamically acquired cross-certificate would trump a builtin token in path validation.  Is that desired behavior?  Wouldn't that imply that since I agreed to pull my request for EV enablement of my GTE root, all Firefox users who have accessed a site that relies on the cross-certificate will continue to rely on it and therefore not receive EV UI?

Comment 7

[Eddy Nigg (StartCom)]

Testing https://secure.ichotelsgroup.com/ which shows a chain to the Cybertrust Global Root and is apparently cross-signed by the GTE root (by chaining to it) and with the patch from bug 493259 applied shows the EV UI correctly. If the site ichotelsgroup.com is a typical setup, than your certificates should be fine and correctly display the EV UI.

Comment 8

[Steven Medin]

Thanks for the help, Eddy.  I need one matter clarified since I don't have a patched DLL.  Can you please confirm that when you view the path, you see the GTE root as the trusted anchor, you see the Cybertrust Global Root's cross-certificate, and you get EV UI?  If our results differ, excluding that you have the EV patch applied, then I can't be confident yet that EV UI will present for consumers who have already used Firefox to access my customers' EV-signed sites.  I need to delete the cross-certificate before I get a chain that terminates in the self-signed CT root.  It is possible that you have never accessed a site that chains through the CT cross-certificate before doing your testing.

That install is typical of our design explained to our customers in their installation instructions, allowing user agents that trust the CT root to short-circuit the provided issuers in the TLS handshake to an EV-enabled embedded trust point while relying on the GTE root for legacy support.

Comment 9

[Eddy Nigg (StartCom)]

(In reply to comment #8)
> Thanks for the help, Eddy.  I need one matter clarified since I don't have a
> patched DLL.  Can you please confirm that when you view the path, you see the
> GTE root as the trusted anchor, you see the Cybertrust Global Root's
> cross-certificate, and you get EV UI?

Let me add some screen shots to confirm that we see and mean the same thing. 

> That install is typical of our design explained to our customers in their
> installation instructions, allowing user agents that trust the CT root to
> short-circuit the provided issuers in the TLS handshake to an EV-enabled
> embedded trust point while relying on the GTE root for legacy support.

I think it works as expected.

Comment 10

[Eddy Nigg (StartCom)]

Attachment: No EV support, chains to legacy root

Comment 11

[Eddy Nigg (StartCom)]

Attachment: With EV support, chains to legacy root and shows the EV UI

Comment 12

[Steven Medin]

That's a win.  Thanks very much for the extra help, Eddy.

Comment 13

[Nelson Bolyard (seldom reads bugmail)]

Steve, 
Here is some additional info that should help explain what you see in the 
cert path displayed in the cert viewer.  

For EV sites, Firefox 3.x does two separate path builds and path validations.

The first asks the question: Is this a valid SSL server (without regard to EV)?
It attempts to build a path to a trusted root without regard to cert policies.
As it builds the patch, from leaf (EE) to root, at each step, if it finds it
has multiple possible unexpired issuer certs from which to choose, it picks 
the "newest" one.  It gives no preference to trusted certs, but always picks 
the "newest" one.  If this algorithm succeeds in building a patch to a root trusted for SSL, and if the EE cert passes a revocation test, it declares that 
the path is a valid SSL server path.

Then, if the EE cert has a known EV policy OID, Firefox does a second path 
build and path validation to ask "Is this a valid EV cert?".  For the second 
build, it collects the root CA cert(s) that is/are approved to issue that 
EV policy OID, and then tries to construct a path to any of those certs.  
In this pass, it does not try only the newest cert at each step, but rather
it does a full tree walk, trying potentially each issuer cert at each step.
It pays full attention to policy extensions in this second path.  If it 
succeeds in building a path to one of the roots trusted for that policy OID
and if the certs in the path pass revocation checks, it declares the path 
valid for EV.  

These two passes may build and verify different cert paths (obviously).  
The cert viewer dialog ALWAYS shows the path built in the first pass, not
the one built in the second pass.  That means that it is possible for you 
to see the "green bar" and yet see a cert path displayed that does not look
like it qualifies for the green bar.  The moral of this story is: don't be
too alarmed by what you see in the cert path display, because it is not a 
good predictor of the presence of the green bar. 

There are several requests for enhancement about all this.  One requests 
that Firefox display the path from the second pass, after it has determined
that the site is an EV site.  Another requests that Firefox always use the 
second algorithm (the one that does the full tree walk) for both passes.  
I do not expect either of those requests to be implemented soon.

Comment 14

[Nelson Bolyard (seldom reads bugmail)]

Fixed by checkin of patch for bug 493660.  Will be in FF 3.5