Closed
Bug 485155
Opened 16 years ago
Closed 16 years ago
NSS_ENABLE_PKIX_VERIFY=1 causes sec_error_unknown_issuer errors
Categories
(NSS :: Libraries, defect, P2)
NSS
Libraries
Tracking
(Not tracked)
RESOLVED
FIXED
3.12.4
People
(Reporter: rob, Assigned: alvolkov.bgs)
References
()
Details
(Whiteboard: PKIX MOZ)
Attachments
(2 files, 1 obsolete file)
(deleted),
patch
|
nelson
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
nelson
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.8pre) Gecko/2009032509 Minefield/3.0.8pre
Build Identifier: trunk
With the current Firefox CVS code + NSS HEAD + NSS_ENABLE_PKIX_VERIFY=1, some https sites give the error...
"The certificate is not trusted because the issuer certificate is unknown.
(Error code: sec_error_unknown_issuer)"
These sites include:
https://www.verisign.com
https://www.globalsign.com
https://secure.comodo.com
https://sha256.tbs-internet.com
Some https sites don't give this error, including...
https://www.entrust.net (EV, and EV UI shown)
https://www.networksolutions.com (EV, but no EV UI shown due to missing AIA->OCSP in the Intermediate CA certificate and end-entity certificate)
https://www.softballoutlet.com (EV, but no EV UI shown due to missing AIA->OCSP in the Intermediate CA Certificate)
https://www.trustwave.com (EV, but no EV UI shown due to missing AIA->OCSP)
https://www.startssl.com (non-EV)
When NSS_ENABLE_PKIX_VERIFY=1 is not set, I don't see the sec_error_unknown_issuer error with any of these sites.
Could this be related to bug #479508? I think some behaviour has changed since I wrote bug #479508 comment #2 a month ago.
Reproducible: Always
Comment 1•16 years ago
|
||
I would say you experience bug 444404.
Reporter | ||
Comment 2•16 years ago
|
||
Yes, probably. But...
IINM, bug #444404 is only about error misreporting. To misreport an error, libPKIX must first believe that an error has occurred!
I don't believe that there are any errors with the certificates used by https://www.verisign.com, https://www.globalsign.com, etc.
Therefore, I conclude that this is a new libPKIX bug.
Comment 3•16 years ago
|
||
Rob, I made one mistake. I didn't realize I have to test this on Gecko 1.9.0 (FF3.0) and not on mozilla-central (Gecko 1.9.6 = FF3.6).
Comment 4•16 years ago
|
||
On mozilla-central with patch for bug 479029 and actual patches for OCSP AIA inject I don't get any load errors for https://www.globalsign.com/.
I'm reproducing for others in the first list above.
Confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 5•16 years ago
|
||
I'm not sure that this bug is valid. As I understand it, it says that
FF 3.0.x doesn't seem to show EV correctly for some sites when
NSS_ENABLE_PKIX_VERIFY is set. I think we knew that, and there is another
bug about that already. But I think we don't intend to fix that. Having
FF 3.0.x work with NSS_ENABLE_PKIX_VERIFY=1 is not a stated goal of FF 3.0.x
AFAIK.
I think we intend to make it work for FF 3.next (a.k.a., Shiretoko, FF 3.5?).
So, I think it would be much more meaningful if this bug said that it doesn't
work with Shiretoko. But I think that Honza has written in comment 4 that it
DOES work with Shiretoko. So, is this bug valid, as is?
Comment 6•16 years ago
|
||
I didn't test this with FF 3.0 yet. I tested with mozilla-central and I *CAN* reproduce the issue for all sites listed in the description but globalsign.com. So there really is a new bug, but it might be a duplicate I am not aware of.
Reporter | ||
Comment 7•16 years ago
|
||
In reply to comment #5:
> Having FF 3.0.x work with NSS_ENABLE_PKIX_VERIFY=1 is not a stated goal of FF
> 3.0.x AFAIK.
In that case, by all means treat this bug's original "Description" as a WONTFIX.
> I think we intend to make it work for FF 3.next (a.k.a., Shiretoko, FF 3.5?).
> So, I think it would be much more meaningful if this bug said that it doesn't
> work with Shiretoko. But I think that Honza has written in comment 4 that it
> DOES work with Shiretoko. So, is this bug valid, as is?
I'm only just getting started with Mercurial today...
With mozilla-1.9.1 (Shiretoko) and NSS_ENABLE_PKIX_VERIFY=1, I get:
https://www.entrust.net (EV UI shown)
https://www.globalsign.com (EV UI shown)
https://www.securetrust.com (EV UI shown)
https://www.trustwave.com (EV UI shown)
https://www.verisign.com (EV UI shown)
https://www.softballoutlet.com (EV UI shown)
https://www.startssl.com (new blue UI shown)
https://www.networksolutions.com (EV UI shown, albeit only briefly)
https://sha256.tbs-internet.com (new blue UI shown, albeit only briefly)
https://secure.comodo.com (crashes the browser!)
If certain Intermediate CA certs are cached in the Shiretoko "Certificate Manager", I see the EV UI for https://secure.comodo.com instead of a browser crash.
Should I be testing Shiretoko with NSS HEAD instead (given the imminent landing of NSS 3.12.3)? If so, how would I do that? (I don't see any "NSS_CO_TAG=" declaration in Shiretoko's client.mk).
Reporter | ||
Comment 8•16 years ago
|
||
With mozilla-central and NSS_ENABLE_PKIX_VERIFY=1, I get:
https://www.entrust.net (EV UI shown)
https://www.globalsign.com (sec_error_unknown_issuer)
https://www.securetrust.com (new blue UI shown; EV UI not shown due to missing AIA->OCSP)
https://www.trustwave.com (new blue UI shown; EV UI not shown due to missing AIA->OCSP)
https://www.verisign.com (sec_error_unknown_issuer)
https://www.softballoutlet.com (sec_error_revoked_certificate)
https://www.startssl.com (new blue UI shown)
https://www.networksolutions.com (new blue UI shown, albeit only briefly; EV UI not shown due to missing AIA->OCSP)
https://sha256.tbs-internet.com (sec_error_unknown_issuer)
https://secure.comodo.com (sec_error_unknown_issuer)
mozilla-central's NSS looks slightly newer than the one in mozilla-1.9.1, but it's not as new as NSS HEAD. Am I therefore testing the wrong combination?
Updated•16 years ago
|
Whiteboard: PKIX
Target Milestone: --- → 3.12.3
Version: unspecified → trunk
Updated•16 years ago
|
Assignee: nobody → alexei.volkov.bugs
Priority: -- → P2
Assignee | ||
Updated•16 years ago
|
Whiteboard: PKIX → PKIX MOZ
Reporter | ||
Comment 9•16 years ago
|
||
Further to comment #7:
> With mozilla-1.9.1 (Shiretoko) and NSS_ENABLE_PKIX_VERIFY=1, I get:
> ...
> Should I be testing Shiretoko with NSS HEAD instead (given the imminent
> landing of NSS 3.12.3)?
Now that NSS 3.12.3 has been pushed to mozilla-1.9.1 (Shiretoko), I get:
Works as expected:
https://www.entrust.net (EV UI shown)
https://www.networksolutions.com (EV UI shown [relying on default OCSP Responder URL], albeit only briefly [mixed HTTP/HTTPS content?])
https://www.softballoutlet.com (EV UI shown)
https://www.securetrust.com (new blue UI shown [EV UI not shown due to no OCSP capability])
https://www.trustwave.com (new blue UI shown [EV UI not shown due to no OCSP capability])
https://www.startssl.com (new blue UI shown)
Unexpected behaviour:
https://www.verisign.com (sec_error_unknown_issuer)
https://www.globalsign.com (sec_error_unknown_issuer)
https://sha256.tbs-internet.com (sec_error_unknown_issuer)
https://secure.comodo.com (sec_error_unknown_issuer)
(Before visiting each of these sites, I cleared out all of the cached Intermediates from the Certificate Manager and restarted the browser).
In reply to comment #5:
> I think we intend to make it work for FF 3.next (a.k.a., Shiretoko, FF 3.5?).
> So, I think it would be much more meaningful if this bug said that it doesn't
> work with Shiretoko.
It doesn't work with Shiretoko.
Flags: blocking1.9.1?
Comment 10•16 years ago
|
||
(In reply to comment #9)
> It doesn't work with Shiretoko.
Rob, what version exactly did you use for your tests? Using a recent nightly build (from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.1/), I can't reproduce the "Unexpected behavior" you describe, actually... in my tests (using a fresh profile), www.verisign.com and secure.comodo.com show the proper EV UI, and www.globalsign.com and sha256.tbs-internet.com are treated as standard SSL sites. No sec_error_unknown_issuer errors in my case.
Comment 11•16 years ago
|
||
Oh, wait... maybe I misunderstood your last sentence in comment 9. Setting NSS_ENABLE_PKIX_VERIFY=1 and then starting Shiretoko gives me the same results, that's right.
Updated•16 years ago
|
Target Milestone: 3.12.3 → 3.12.5
Assignee | ||
Comment 12•16 years ago
|
||
The failure in cert patch validation was caused by using wrong eku oids when checking intermediate ca certs.
To fix the problem I propose to add nss cert type verification function to pkix cert object and use it to validate key usages and extended key usages the same was we do it in legacy nss code.
Attachment #372527 -
Flags: review?(nelson)
Comment 13•16 years ago
|
||
Comment on attachment 372527 [details] [diff] [review]
(wrong patch)
I think this must be the wrong patch. I've reviewed this patch before. Parts of this patch (maybe all of it) is already checked in. And only 3 lines out of this huge patch have anything to do with nsCertType. So I think this is just the wrong patch.
If the real patch is buried in here somewhere, then let's discuss this.
Attachment #372527 -
Flags: review?(nelson) → review-
Assignee | ||
Updated•16 years ago
|
Attachment #372527 -
Attachment description: Patch v1 - use nss cert type value through out libpkix to verify certificate usages → Patch v1 - use nss cert type value through out libpkix to verify certificate usages(wrong patch)
Assignee | ||
Comment 14•16 years ago
|
||
Attachment #372692 -
Flags: review?
Assignee | ||
Updated•16 years ago
|
Attachment #372692 -
Flags: review? → review?(nelson)
Assignee | ||
Updated•16 years ago
|
Attachment #372527 -
Attachment is obsolete: true
Updated•16 years ago
|
Attachment #372692 -
Flags: review?(nelson) → review+
Comment 15•16 years ago
|
||
Comment on attachment 372692 [details] [diff] [review]
Patch v2 - use nss cert type value through out libpkix to verify certificate usages
r=nelson (except for ssl.sh :)
Updated•16 years ago
|
Attachment #372527 -
Attachment description: Patch v1 - use nss cert type value through out libpkix to verify certificate usages(wrong patch) → (wrong patch)
Reporter | ||
Comment 16•16 years ago
|
||
Nelson, Alexei,
What is this patch diff'd against?
I get failed hunks when I try to apply it. I've tried mozilla-1.9.1, mozilla-central and CVS+NSS HEAD.
Thanks.
Comment 17•16 years ago
|
||
Johnath - do we need to relnote this for b4? What's the actual impact to users here?
Comment 18•16 years ago
|
||
Mike,
This only affects people who run the browser after setting the environment variable NSS_ENABLE_PKIX_VERIFY=1. I think all such people in the world
are CC'ed on this bug. :)
Reporter | ||
Comment 19•16 years ago
|
||
> I think all such people in the world are CC'ed on this bug.
That could well be true right now. :-)
Nelson, in comment #5 you said "I think we intend to make it work for FF 3.next (a.k.a., Shiretoko, FF 3.5?)". Therefore, I've been working on the assumption that NSS_ENABLE_PKIX_VERIFY=1 might be the default behaviour when FF3.5 is actually released.
If my assumption is (or might yet prove to be) correct, please don't let this bug drop off the radar.
If my assumption is definitely incorrect, then please say so. Thanks.
Comment 20•16 years ago
|
||
Rob,
When this bug is fixed, it will still not be the case that NSS 3.12.x will
have the NSS_ENABLE_PKIX_VERIFY=1 behavior by default. To get that behavior,
an application must either set that environment variable or call CERT_SetUsePKIXForValidation(PR_TRUE).
You'll recall that Bug 479393 proposes to have PSM do that call.
Bug 479393 cannot be committed until this bug is fixed.
This bug is not yet fixed in the NSS source tree. I am optimistic it will
be done by middle of next week. But whether that will be done in time for
FF 3.5, and whether the Firefox developers will "take" that version of NSS,
and also take the fix for bug 479393, for FF 3.5 is not yet known, and is
not entirely under the NSS team's control.
Reporter | ||
Comment 21•16 years ago
|
||
Nelson, thanks for the explanation.
Assignee | ||
Comment 22•16 years ago
|
||
Assignee | ||
Updated•16 years ago
|
Attachment #373669 -
Attachment is patch: true
Attachment #373669 -
Attachment mime type: application/octet-stream → text/plain
Comment 23•16 years ago
|
||
Comment on attachment 373669 [details] [diff] [review]
Patch v3 - as it was checked in last night.
I am asking myself to review this patch.
Attachment #373669 -
Flags: review?(nelson)
Updated•16 years ago
|
Attachment #373669 -
Flags: review?(nelson) → review+
Assignee | ||
Updated•16 years ago
|
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Updated•16 years ago
|
Flags: blocking1.9.1? → blocking1.9.1-
Updated•15 years ago
|
Target Milestone: 3.12.5 → 3.12.4
Updated•14 years ago
|
Blocks: pkix-default
You need to log in
before you can comment on or make changes to this bug.
Description
•