Closed Bug 419678 Opened 13 years ago Closed 13 years ago

broken verification of www.sffutureroot.com

Categories

(NSS :: Libraries, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: KaiE, Unassigned)

References

()

Details

Firefox 3 using NSS 3.12 beta 2
(PSM has the patch for bug 418958 applied, but that shouldn't matter.)

I'm testing bug 418958.
Note that here are some cross certificates in use.
You might be interested to read bug 403437 comment 10 and 11.

For testing purposes, I removed two certs from the root store:
  "Go Daddy Class 2 CA"
  "ValiCert Class 2 VA"

Talking about Go Daddy related roots, the builtin module still contained the cert:
  "Starfield Class 2 CA"

Now I attempted to visit the demo server
  https://www.sffutureroot.com/

On the first connect during the session, I get an SSL error page that reports:
  sec_error_unknown_issuer

This is surprising, because this server is supposed to be a test server for the Starfield root.


Now, what is even more surprising:
I simply hit "reload", causing the connection/verification to be attempted again.

To my surprise, this works!
And we're even able to validate it as EV!


Reproducable: always
Blocks: 418958
Just a clarification:  https://www.sffutureroot.com/ does NOT present a chain that uses a cross cert.  The chain served from that site is server_cert -> issuing CA -> Starfield Root CA.

For comparison purposes, a similar test site exists at https://www.gdfutureroot.com/ that also presents a chain that does not include a cross cert.  The chain served is server_cert -> issuing CA -> GoDaddy Root CA.

If gdfutureroot works but sffutureroot fails, this seems to indicate a problem specific to the Starfield Class 2 CA.
I'm not sure there's any bug here.  I think the observed events can perhaps
be explained as the expected consequence of ordinary events.  

Consider the following scenario:
1. Starting with a root cert list that lacks Starfield Root CA, and an empty
cert DB (or, a cert DB that is empty of any CA certs related to StarField,
Godaddy, etc.) you visit an https URL for a server that serves a chain that
is anchored by the Starfield root, which your browser does not have, so 
the browser correctly reports sec_error_unknown_issuer.

2. In another window or tag, you visit some server whose cert chains up to 
some other root, using a cross certificate for the Starfield root.  
This chain verifies, and consequently, the intermediate CA certs in that 
chain are added to your cert DB.  Now, that cross cert is in your cert DB.

3. In the original tab/window, you click "reload".  This time, the chain 
validates, even though you still do not have the Starfield root CA in your
cert DB or root list.  It succeeds because as it builds the chain for that
server's cert, this time it finds the cross certificate for the Starfield 
root, and using that cert it constructs a chain to a known and trusted root.

Does that explain your observations, Kai??

.
Nelson, no, I did not visit any other site that would give me missing roots.

I start Firefox, I visit the URL, I get the error, I hit reload, then it works.

There is no other activity happening in between those event.

Well, I could imagine only a single possible reason. OCSP. Maybe the OCSP repsonder provides a missing intermediate?

But I don't think that is likely either.
Because in Firefox 3 we have started to permanently cache all valid intermediates, I should have run in this bug only once.

But I can reproduce this bug simply by restarting the browser.
I'm really confused now.

First, I tried to repeat the above scenario.
I can no longer reproduce the bug.
I now get a good connection at first attempts.
I'm absolutely sure that my information shown in the previous comment correctly describes my tests as of yesterday.


I also tried to disable OCSP and used an empty cert DB.
I get a good DV connection on first attempt.
This makes no sense to me right now.

I have no idea why the first-connection-during-session would have failed yesterday.
I think I used a broken environment when I ran into this bug, see bug 418958 comment 4.

Resolving as INVALID.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.