173939 - Cannot connect to secure site: "The page requires a client certificate"

Status: CLOSED DUPLICATE of bug 174634

(Core Graveyard :: Security: UI, defect, P1)

Description

[Torben]

User-Agent:       Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.2b) Gecko/20021009
Build Identifier: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.2b) Gecko/20021009

I cannot connect to my bank's site with the newest moz-builds: 1.1 until build
2002092308 works, 2002100108 and forward does not (cannot test builds in between
since they does not run on win95). This seems to corelate to update of nss3.dll
from ver 3.5.1beta to 3.6beta.

Reproducible: Always

Steps to Reproduce:
1. Go to url (http://www.skandiabanken.no/SKSecure/NO)
2. Click "Logg inn"-button


Actual Results:  
Error page appears: The page requires a client certificate.


Expected Results:  
1. You should be asked for your master password
2a. If you have a valid certificate you should be taken to the login-page, or
2b. if you do not have a certificate you should be taken to a "Download
certificate"-page.

Comment 1

[Torben]

Forgot to mention that you even don't get asked for your master password.

Comment 2

[John Unruh]

What I see appears to be expected behavior.
1.) First, Edit>Prefs>privacy>Certificates. Select Ask every time.
2.) Visit https://www.skandiabanken.no/SKSecure/NO
3.) A dialog box appears asking me to choose a certificate.
4.) I select one, and am asked for my master password.
5.) I get a page worded "The page requires a valid client certificate". That is
expected, since I don't have a valid cert.
The 8/26 Mozilla build behaves the same as the 10/10 build.
From the original comment - "2b. if you do not have a certificate you should be
taken to a "Download certificate"-page." That is up to the web site to determine
what page gets displayed when client authorization fails.

Also, if you are not asked for your master password, you may already be logged
in to your master password.

Reporter, you might check to see if your certificate has expired, or try
exporting the certficate, (in case your cert DB is corrupted), setting up a new
profile, importing the cert, and attempting to log in again.

Comment 3

[Torben]

Re #2:
> "2b. if you do not have a certificate you should be
> taken to a "Download certificate"-page." That is up to the web site to 
> determine what page gets displayed when client authorization fails.

Yes, and earlier builds have always taken me to the download page if my
certificate has been missing, expired or corrupted. Also I cannot doenload a new
certificwte with 2002100108 and forward, going to the download certificate page
(https://www.skandiabanken.no/skcert/no/index.asp?cert=1) and filling in correct
information just reloads the page instead of submitting it.

> Also, if you are not asked for your master password, you may already be logged
> in to your master password.

No.

> Reporter, you might check to see if your certificate has expired

Certificate is OK, works with 1.1 and 2002092308

> try exporting the certficate, (in case your cert DB is corrupted), setting up
 > a new profile, importing the cert, and attempting to log in again.

Done before the bug was filed, doesn't help.

Comment 4

[Kai Engert [:KaiE:]]

Sorry, but I can not reproduce your problem.

I tried various versions of Mozilla. I tried:
- 1.0.1
- 1.1 alpha
- 1.1 beta
- 1.1
- 1.2 alpha

Test series 1:
If I do not own a certificate, and go to above URL, I immediately see the error
message.

Test series 2:
If I DO own a certificate, and go to above URL, I'm prompted to enter my master
password, but afterwards see the same error message.

Regardless which version I use, I always saw the exact same behaviour.


I suspect something changed in your profile, and you just think the new
behaviour is caused by Mozilla?

If you want this bug fixed, please try to give a better reproducable test case.
Please try yourself with the different versions, using a new profile.

Comment 5

[Torben]

Re #4:
> I suspect something changed in your profile...
No, I have used the same profile for all moz-builds, works upto 2002092308,
fails with 2002100108 forwards.

> Please try yourself with the different versions, using a new profile.

As stated in #3 did before filling bug, retried todaay testing all builds with
new profile and fresh certificate, same problem.

[e-mail] and Kai Engert, which OS did you test with? Maybe this is a
win95 problem only?

As stated in #0 this problem began when nss3.dll was updated, is there a way for
me to change which file moz will use? Just replacing the file with an older
version will make moz complain that PSM is missing.

Comment 6

[Torben]

Usong dependencywalker I have profiled what happens when I try to log with
moz1.1 and build 2002101408. I will attach the output from where I click on the
"Logg inn" button. The interesseting differences seems to be line 138-151 from
1.1 (mozilla11log.txt) compared with lines 138-144 from 2002101408
(mozillaNlog.txt).
Note that wallet.dll never get called with 2002101408.

Comment 7

[Torben]

Attachment: Output from dependencywalker wit Moz1.1

Comment 8

[Torben]

Attachment: Output from dependencywalker with build 2002101408

Comment 9

[John Unruh]

Reporter, please try again after bug 164260 is fixed.

Comment 10

[Torben]

I think I found the problem (due to bug 171331 comment 30): in builds 2002100108
forwards when veiwing the details of the certificate I get that "Could not
verify this certificate because the issuer is unknown". In 1.1 it instead says: 
"This certificate has been validated for the following uses:
SSL Client Certificate
SSL Server Certificate
Email Signer Certificate
Email Recipient Certificate"

I can attach screenshots of this if necessary.

Comment 11

[Lasse Marøen]

I'm seeing this too, winXP 2002101412. Been like this for a couple of weeks, I
thought it was bug 171331 and being worked on. 

Confirming. 

Comment 12

[Kai Engert [:KaiE:]]

If I understand you correctly, you can fix the problem by going back to an older
build, and going forward to a newer build makes the problem show up again,
without changing anything in the profile.

Since you are the only ones who can reproduce the problem, it would be helpful
if you could track down the breakage to a single date. I'm not sure if you have
done that already. Like: You currently know there is an old build that works,
and a new build that does not work, but the difference between the dates is more
than one day.

If we knew on which date exactly the regression starts, we could try to read the
changes made on that date.

I ask because a lot of changes happened between 2002/09/23 and 2002/10/01. In
particular:
- on 2002/09/23 a lot of code changed within PSM itself
- on 2002/09/26 NSS was moved to a new version.

It would be helpful to know, whether the changes to PSM or the changes to NSS
have caused the problem.

Comment 13

[Lasse Marøen]

Kai: I'll do some serious checking later today.

Comment 14

[Torben]

> If I understand you correctly, you can fix the problem by going back to an
> older build, and going forward to a newer build makes the problem show up
> again, without changing anything in the profile.

That's right.

> Since you are the only ones who can reproduce the problem,

Not anymore it seems... (re comment 11)

> it would be helpful if you could track down the breakage to a single date. 
> ...

Unfortuanly moz-builds between 2002092308 and 2002092908 want launch on win95
(bug 170969) (I couldn't find the 20020929xx and 20020930xx builds anymore when
I noticed this bug)

> I ask because a lot of changes happened between 2002/09/23 and 2002/10/01. 
> In particular:
> - on 2002/09/23 a lot of code changed within PSM itself
> - on 2002/09/26 NSS was moved to a new version.

Lasse, can you test this? I still have nigthly builds from 2002-09-23 until
2002-09-28 available if you cannot find them anymore.

Comment 15

[John Unruh]

*** Bug 175274 has been marked as a duplicate of this bug. ***

Comment 16

[Lasse Marøen]

I've been testing a bunch of builds and this definitely broke somewhere between
2002-09-29 and 2002-10-01. I haven't been able to find any windows builds from
2002-09-30, if anyone finds one please give me an url and I'll try it.

Comment 17

[Kai Engert [:KaiE:]]

Do you say, 2002-09-29 works, but 2002-10-01 does not?

There have been no checkins to PSM during that time.
I do not know whether NSS checkins were made during that time.

Comment 18

[Lasse Marøen]

Yes. After I narrowed it down to those two builds I've been going back and forth
between them a couple of times to make sure. If you can point me to a 9/30 build
I can narrow it down further.

Comment 19

[Wan-Teh Chang]

Kai,

Unfortunately I don't remember if there were NSS changes
made between 2002-09-29 and 2002-10-01.  Sorry.

It is likely that I changed NSS from NSS_3_6_BETA2 to
NSS_3_6_BETA3 during that period.

The current NSS_CLIENT_TAG (as of today) is identical to
NSS_3_6_BETA3.  Kai, if you can reproduce this bug, I
suggest that you drop in the NSS_3_6_BETA2 DLLs and see
if the problem disappears.  You can get NSS_3_6_BETA2
DLLs from /share/builds/sbsintegration/nss/NSS_3_6_BETA2.
Use WIN954.0_DBG.OBJD for debug build or WIN954.0_OPT.OBJ
for optimized build.

Comment 20

[John Unruh]

Reporter, are installing over an old build? If so, can you try installing a
recent build in a new directory?

Comment 21

[Kai Engert [:KaiE:]]

Unfortunately, I am unable to reproduce the problem myself, but Lasse, you can
help us make the test.

Please produce a special environment to test with. It will be a mixture of both
builds.

Please copy all files from the 2002-10-01 build to a new directory
2002-10-01-with-NSS-from-09-29.

Remove the following files from your 2002-10-01-with-NSS-from-09-29 directory:
nss3.dll
nssckbi.dll
smime3.dll
softokn3.dll
ssl3.dll

Now copy the same files from the 2002-09-29 build over to that directory, and
run mozilla from that directory.

If this fixes the problem, we know for sure that we have to search the problem
within NSS.

Comment 22

[Lasse Marøen]

Kai: I followed your instructions, and as you assumed the bug is not present in
that environment. So it's definitely a problem with NSS.

Comment 23

[Brian Heinrich]

I realise this isn't my bug, so please pardon the spam, but having looked over
it in connexion with Bug 171331, the similarities between the two suggest that
Bug 175085 would be a more appropriate dependency than Bug 164260.

Comment 24

[Torben]

I too have done the test outlined in comment 21 and can confirm Lasse's results
(comment 22): using the NSS_3_6_BETA3 files (from build 2002100108)the
connection will fail in all tested builds, with the NSS_3_6_BETA2 files (from
build 2002092808) everything goes OK. Build tested 2002092308, 2002100108 and
1.2beta.
I agree with Brian (comment 23), this probably has nothing to do with bug 164260
(wrong timeframe), changing dependencies.

Comment 25

[John Unruh]

*** Bug 175490 has been marked as a duplicate of this bug. ***

Comment 26

[John Unruh]

*** Bug 175734 has been marked as a duplicate of this bug. ***

Comment 27

[Nelson Bolyard (seldom reads bugmail)]

I'm trying to understand what the real bug (if any) is here.  
I think the submittor's "expected behavior" is not correct.  
The submittor expects that you will be asked for your "master" password
whether or not you have a client certificate.  
That is NOT the proper expected behavior.  

You should be asked for your "master password" (actually, it's your crypto 
token password) when you need to use your private key and you are not 
already logged in to your crypto token.  

The expected sequence of events is that 
1. The server requests client authentication and specifies a list of CAs
from which it will accept a client cert.  
2. The client looks to see if it has any unexpired client certs from any 
of the CAs named by the server, for which it has the private key.  
3. If not, the client responds to the server that it has no cert.
4. If so, the client may ask the user to select one.  Then the client 
needs to use the private key, and it should _only_then_ ask for a password.

It sounds like the client's behavior is consistent with it finding that it 
has no unexpired certs from (issued by) any of the CAs named by the server,
for which it has the private key.  

Is it possible that you have lost the private key for this certificate?

Comment 28

[Kjetil Svenheim]

This is indeed a real bug. I have also experienced this problem, and it was
easily resolved by installing a different version of Mozilla. I havent used any
nightly builds, but the problem is in Mozilla 1.2b, and not in Mozilla 1.1 or
any previous versions.

The personal certificate is not missing, but this is what's reported when the
address in question is tried accessed. So there clearly must be a bug which
makes this certificate "undetectable" by the website.

Unfortunately I know little or nothing about programming, I am just saying that
we're more than one who has experienced this problem, and I know several other
people who use the same net bank and have the same problem with version 1.2b.

Comment 29

[Lasse Marøen]

I'm not sure about the details in the original report, but I'm pretty sure about
this:

* You cannot log in to the bank
* This broke in NSS between 9/29 and 10/1
* This is not profile related, I can go back and forth between a build that
works and one that doesn't using the same profile.

Unfortunately, I'm also pretty sure you need to have an account in the bank to
reproduce this bug. I have to provide my user name and password to download a
certificate. 

Comment 30

[Wan-Teh Chang]

Attachment: Diffs between NSS 3.6 Beta2 and NSS 3.6 Beta3

The NSS change between 9/29 and 10/1 is likely to
be the upgrade from NSS 3.6 Beta2 to NSS 3.6 Beta3
or a subset of it.

This patch file contains all the changes between
NSS 3.6 Beta2 and NSS 3.6 Beta3.  Hopefully we can
spot the change that caused this bug.

Comment 31

[Wan-Teh Chang]

Changed product to NSS and assigned the bug to Nelson.

Comment 32

[Nelson Bolyard (seldom reads bugmail)]

My thanks to Kjetil Svenheim who sent me his cert DB, with which I was
able to determine the problem.  

I believe this problem is another manifestation of bug 159383 due to the 
regression reported in bug 174634.  The problem occurs when libSSL calls
CERT_CertChainFromCert to construct the DER cert chain to send out. 
The chain it gets back has only the leaf cert, not the intermediate CA
cert, because the leaf contains an authority key ID that includes the 
issuer's issuer and SN.  When I apply the patch for bug 174634, the 
chain that comes back from CERT_CertChainFromCert includes the intermediate
CA cert.  

Naturally, we won't know for certain that this completely solves the problem
until one of these users can succesfully login to the bank again.  
But once that's done, I think we can mark this bug a duplicate of bug 174634.

Comment 33

[Lasse Marøen]

Cool! Is it checked in to the trunk yet? I see that bug 174634 is marked fixed,
but the patch doesn't have sr or a.

Comment 34

[Nelson Bolyard (seldom reads bugmail)]

NSS tree rules are quite different from mozilla browser source rules.
No SR required for the trunk.  Mozilla doesn't pull from the trunk, not
even for nightly builds.  It pulls from a CVS "sticky tag", which gets
changed when NSS does a Beta or a release.  The date on which you notice
the problem began was when the tag changed for NSS 3.6 Beta 2 or Beta 3.
The fix is on the trunk, but I don't know how long before the tag will
change.  If you do your own builds, you can easily pull NSS from the trunk
for your own builds.

Comment 35

[Torben]

Adding bug 174634 to dependency list dur to comment 32.

I also think that it would be appropiate to resolve this as fixed when the patch
to bug 174634 get checked into the trunk, and not as a dupe (partly due to the
discussion about a bugzilla point system in netscape.public.mozilla.general,
especially as this bug is the oldest)

Comment 36

[Wan-Teh Chang]

I sent a request for mozilla trunk approval for bug 174634
to [e-mail] yesterday.

Meantime, I put a Win32 DLL with the fix at
ftp://ftp.mozilla.org/pub/security/nss/tmp/bug173939/nss3.dll.

You can test the fix by replacing the nss3.dll file in your
Mozilla installation with the nss3.dll file from the FTP URL
above.  Please report here whether that nss3.dll solves the
problem for you.  Thanks.

Comment 37

[Lasse Marøen]

Yes, it works! Using the dll you provided with the latest trunk nightly I can
log in to the bank without problems. Thanks! Now I can pay my bills....

Comment 38

[Nelson Bolyard (seldom reads bugmail)]

Re: Comment 35

The patch is already checked in on the trunk.  
Mozilla builds do not pull NSS sources from the trunk.
What is needed is NOT for the patch to be checked in on the trunk,
but rather for the CVS tag used by the browser builds to be advanced
to a newer revision on the trunk (or a branch).


*** This bug has been marked as a duplicate of 174634 ***

Comment 39

[John Unruh]

Verified dupe.

Comment 40

[Kai Engert [:KaiE:]]

Nelson, I would prefer it we tracked whether a fix arrived in PSM or not by bug
status.

I understand that you fixed the bug in NSS, but that does not have an impact on
PSM, and it is sometimes difficult to track.

I suggest that for each bug in PSM, where the cause is a NSS bug, we should have
two bugs. The NSS bugs, that blocks the PSM bug. And the PSM bug, that does not
get marked as resolved as long as the fix has not been moved to the NSS_CLIENT_TAG.

If we decide that we do not want separate bugs for NSS and PSM, in that case I
suggest we don't resolve the NSS bug until the fix arrived in PSM.

Comment 41

[Nelson Bolyard (seldom reads bugmail)]

Kai,  I tend to agree that there should be separate bugs for PSM and NSS.
This bug was changed from a PSM bug to an NSS bug.  As an NSS bug, it is 
a duplicate.  If you want to create a separate PSM bug, or reopen this 
bug and change it back to a PSM bug, that's OK with me.  

Comment 42

[Torben]

Reopen and changing component due to comment 40 and 41. Someone else will have
to change the "assigned to"-field.

Kai, maybe you will take this bug?

Comment 43

[Kai Engert [:KaiE:]]

Marking again as a duplicate of 174634. I overlooked that Wan-Teh already tries
to land bug 174634 on the Mozilla trunk / NSS_CLIENT_TAG. It is ok with me to
track that state in bug 174634 (although I fear it might confuse Mozilla drivers
if they see the bug is already marked fixed.)


*** This bug has been marked as a duplicate of 174634 ***

Comment 44

[John Unruh]

Verified dupe.

Comment 45

[Torben]

Confirming that this now works, tested with build 2002102814. Closing bug.