485155 - NSS_ENABLE_PKIX_VERIFY=1 causes sec_error_unknown_issuer errors

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P2)

Description

[Rob Stradling]

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

[Honza Bambas (:mayhemer)]

I would say you experience bug 444404.

Comment 2

[Rob Stradling]

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

[Honza Bambas (:mayhemer)]

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

[Honza Bambas (:mayhemer)]

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.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

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

[Honza Bambas (:mayhemer)]

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.

Comment 7

[Rob Stradling]

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).

Comment 8

[Rob Stradling]

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?

Comment 9

[Rob Stradling]

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.

Comment 10

[Kaspar]

(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

[Kaspar]

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.

Comment 12

[Alexei Volkov]

Attachment: (wrong patch)

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.

Comment 13

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 14

[Alexei Volkov]

Attachment: Patch v2 - use nss cert type value through out libpkix to verify certificate usages

Comment 15

[Nelson Bolyard (seldom reads bugmail)]

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 :)

Comment 16

[Rob Stradling]

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

[Mike Beltzner [:beltzner, not reading bugmail]]

Johnath - do we need to relnote this for b4? What's the actual impact to users here?

Comment 18

[Nelson Bolyard (seldom reads bugmail)]

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.  :)

Comment 19

[Rob Stradling]

> 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

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 21

[Rob Stradling]

Nelson, thanks for the explanation.

Comment 22

[Alexei Volkov]

Attachment: Patch v3 - as it was checked in last night.

Comment 23

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 373669 [details] [diff] [review]
Patch v3 - as it was checked in last night.

I am asking myself to review this patch.