138354 - trust bits are zero for certs on nCipher token with NSS 3.4

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P1)

Description

[Julien Pierre]

This is a regression from NSS 3.3 . In the web server admin UI, we enumerate 
certs using PK11_ListCerts. We also save their trust bits.

On one machine, I have an nCipher device configured with web server. The certs 
have no trust bits when using NSS 3.4. The server requires them to have the 
"user cert" bit in order to be able to use them as server certs. If I replace 
the shared libs with NSS 3.3 , the trust bits are correct.

Comment 1

[Julien Pierre]

Bob,

FYI, the code in question is doing PK11_ListCerts(PK11CertListUser, NULL);

Then it enumerates the CERTCertList and gets the trust via CERT_GetCertTrust.
The trust bits are zero with NSS 3.4 for those certs in the nCipher token; they
are non-zero in NSS 3.3 .

Comment 2

[Ian McGreer]

Attachment: catch trust for user certs

I think Bob fixed this on the tip yesterday.  Here is a patch for the branch.

Comment 3

[Ian McGreer]

Attachment: start trust with zero

Just noticed that needs to be a zalloc...

Comment 4

[Robert Relyea]

My fix for the tip was for a different problem, though it's possible that this
affects the NCipher. I thought my fix simply restored the NSS 3.4 semantics to
NSS 3.4 with the new caching patch.

I'll try it this morning.

bob

Comment 5

[Bishakha Banerjee]

Adding myself to the cc list

Comment 6

[Robert Relyea]

Julien,

I did a build on cert.mcom.com using NSS 3.4 and the user certs all show up
correctly.

bob

Comment 7

[Julien Pierre]

Bob,

What program are you using to check this ?
I still see the problem in the web server even with the patch applied.

I don't see the problem in certutil. But certutil doesn't use PK11_ListCerts I 
believe, and so the behavior may be different.
I also didn't see a problem in certutil before the patch yesterday. The problem 
only manifested itself in the web server UI, which as I mentioned uses 
PK11_ListCerts and CERT_GetCertTrust.

Comment 8

[Julien Pierre]

After further investigation and Bob's help, I found that there are 3 behavior 
changes of NSS that are causing this problem .

The first one is that calling PK11_ListCerts in NSS 3.4 no longer causes the 
password authentication function to be called, and therefore the token isn't in 
the authenticated state.

The server does two calls to PK11_ListCerts, as below :

    // get all the user certs
    CERTCertList* clist;
    clist = PK11_ListCerts(PK11CertListUser, NULL);
    populate(clist);

    // then get all the root certs
    clist = PK11_ListCerts(PK11CertListRootUnique, NULL);
    populate(clist);

With the current code, the first call returns no certs, when it should return 
all the nCipher certs. The second call returns the built-in certs as it should, 
but also the nCipher certs, without any flags. That's what's incorrect.

Bob made a patch for PK11_ListCerts so that it would authenticate. However, that 
still didn't resolve the problem.

I found there was some more code before the PK11_ListCerts that would examine 
the content of the admin form, and call PK11_CheckUserPassword on all the tokens 
that it had the password for. PK11_CheckUserPassword passed, but didn't really 
put the token into the "logged in" state, but it was enough for PK11_ListCerts 
not to authenticate again even with Bob's first patch.

So Bob made a second patch to restore the behavior of PK11_CheckUserPassword, 
which caused an automatic token login upon success.

With these two patches in, the nCipher certs are showing with the correct trust 
bits, as long as the token password is provided.

However, if the token password is not provided, or the wrong one is provided, 
such as the first time the administrator brings up the form, before he gets 
prompted, then the nCipher certs are still showing with zero trust bits, and 
they are returned as part of the second PK11_ListCerts. That's the third 
behavior change of NSS 3.4, which has not yet been resolved.

It's pretty confusing because when you click on these certs that have no bits, 
you get a dialog saying that you need to authenticate to the token.
If you do that, the certs will change position in the list. I would say that it 
would be desirable to have the fix for that third problem in NSS 3.4.1 .

I am checking in Bob's first two patches into NSS_3_4_BRANCH so that it goes 
into 3.4.1 :

Checking in pk11cert.c;
/cvsroot/mozilla/security/nss/lib/pk11wrap/pk11cert.c,v  <--  pk11cert.c
new revision: 1.67.2.1; previous revision: 1.67
done
Checking in pk11slot.c;
/cvsroot/mozilla/security/nss/lib/pk11wrap/pk11slot.c,v  <--  pk11slot.c
new revision: 1.35.2.1; previous revision: 1.35
done

Comment 9

[Julien Pierre]

For that third problem, I should clarify what the old behavior was with 3.3 :
The nCipher certs would not be shown at all unless the user was logged in. I 
think that's preferable to having "half" certs that we are unable to tell 
whether they are user or CA certs. Also the UI doesn't allow authentication 
after clicking on a cert, so the user has to go back to the manage certs 
page right now to login, he can't do it after clicking on one of those 
half-certs ...

Comment 10

[Julien Pierre]

Attachment: test program

Comment 11

[Julien Pierre]

Bob,

I applied your latest patch. It helped the problem, but didn't quite resolve it.
I have just attached a test program I built for this case.

The test program just initializes NSS and then enumerates certificates on the 
nCipher token. It can optionally login. You need to give one argument. If the 
argument is "login" then it will login. Any other argument will cause it not to 
login.

Here is the output of the program with my build of NSS 3.4 :

(cert)/h/strange/export/home/jpierre/60/SunOS_5.8_depend/ns/server/work/B1/SunOS
5.8_DBG.OBJ/alias{97} ./ncipher login
User certs :
Cert found : userpin:ocspSigningCert cert-certmarcs . Trust : 64 .
Cert found : userpin:caSigningCert cert-certmarcs . Trust : 64 .
Cert found : userpin:Server-Cert cert-certmarcs . Trust : 64 .
Cert found : userpin:2048-bits-key-Cert . Trust : 64 .
Unique root certs :

(cert)/h/strange/export/home/jpierre/60/SunOS_5.8_depend/ns/server/work/B1/SunOS
5.8_DBG.OBJ/alias{98} ./ncipher nologin
User certs :
Unique root certs :
Cert found : userpin:caSigningCert cert-certmarcs . Trust : 0 .

As you can see, there is a cert called "userpin:caSigningCert cert-certmarcs" 
which shows up in the user certs with trust 64 when logged in, and in the unique 
root certs with trust 0 when not logged in. That's very strange.
I didn't create that cert on the token so I'm not entirely sure what it is 
supposed to be.

The output of the program with NSS 3.3 is as follows :

(cert)/h/strange/export/home/jpierre/60/SunOS_5.8_depend/ns/server/work/B1/SunOS
5.8_DBG.OBJ/alias{191} ./ncipher login
User certs :
Cert found : userpin:caSigningCert cert-certmarcs . Trust : 72 .
Cert found : userpin:ocspSigningCert cert-certmarcs . Trust : 64 .
Cert found : userpin:Server-Cert cert-certmarcs . Trust : 64 .
Cert found : userpin:2048-bits-key-Cert . Trust : 64 .
Unique root certs :

(cert)/h/strange/export/home/jpierre/60/SunOS_5.8_depend/ns/server/work/B1/SunOS
5.8_DBG.OBJ/alias{192} ./ncipher nologin
User certs :
Unique root certs :

(cert)/h/strange/export/home/jpierre/60/SunOS_5.8_depend/ns/server/work/B1/SunOS
5.8_DBG.OBJ/alias{193} 

I had to slightly modify the initialization in the test program because 
NSS_NoDB_Init in NSS 3.3 didn't load the module from secmod.db . So I used the 
following init line :

    SECStatus rv = NSS_Initialize(".", "", "", "secmod.db", 0);

(this will work with 3.4 too).

As you can see, with 3.3, when logged in the CA cert, which is showing in the 
"user certs" list, has trust bits of 72, whereas they are 64 with NSS 3.4 .

Also, with 3.3, when not logged in, not of the certificates in the nCipher token 
are visible. This is consistent with the behavior we have seen before with most 
other tokens using NSS 3.3 .

Is the new behavior of 3.4, which sometimes shows certs with 0 trust flags, ever 
desirable, and if so what for ?

Comment 12

[Robert Relyea]

OK, I think the '72' is including a ca peer bit, which is a known semantic 
difference between 3.3 and 3.4, so that should be OK.

The appearance of the CA signing cert under 3.4 is actually correct behaviour 
(it's lack of appearance can be considered a bug in 3.3).

What we are looking at is a corner case where we have the actual CA as a user 
cert as well. It's going to be very unlikely to show up in any production Web 
server (You usually want to protect CA keys more strongly).

I think we should go with the patch and spin the release on Monday.

bob

Comment 13

[Julien Pierre]

Fixed check in to NSS 3.4.1.