455554 - invalid OCSP signer cert when smart card is plugged in

Status: RESOLVED INVALID

(NSS :: Libraries, defect)

Description

[Nelson Bolyard (seldom reads bugmail)]

SeaMonkey trunk, using NSS 3.12.1.1 

When I have my Aladdin smart card (USB fob) plugged in, and I visit 
https://www.startssl.com/ I am told that the OCSP signing cert is invalid.
This is repeatable.  The "try again" button always produces the same result.

If I unplug the smart card, and click the "try again" button, I can visit 
the page without any problem.  

This bug will probably turn out to be a duplicate of bug 444974.
I strongly suspect this is related to bug 444850, which fixes a similar bug
that occurs in the presence of misbehaving PKCS#11 modules.  

The cause of this problem may (or may not) also be the cause of bug 454406.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

I can now reproduce this in the debugger.  
It is not related to the fixes committed for bug 444850.  
I had suspected it was a regression due to that bug fix.  It is not.

For reasons not yet clear, the Aladdin PKCS#11 module's slots are all 
listed as the preferred ("default") slots for RSA computations, which 
means that NSS is attempting to do ALL the RSA operations, including
verification of signatures on certificates, in the Aladdin PKCS#11 module
for my smart card token.  It only does this when the token is present,
not when the token is absent, which explains why removing the card makes
the problem cease.

Every second time that NSS attempts to import an RSA public key as a new
"session" (temporary, not persistent) object into the smart card slot, the
operation fails with error 0xd1, CKR_TEMPLATE_INCONSISTENT.  The first 
attempt succeeds, the second attempt fails, the third attempt succeeds, 
the fourth attempt fails, and so on.  This causes every other certificate
signature checked to be found to be bad.  That is probably a defect in the
Aladdin PKCS#11 module.  

But the question is: why does NSS have the Aladdin PKCS#11 slots listed as
"default" slots for RSA operations?  I will investigate that next.

Comment 2

[Eddy Nigg (StartCom)]

Perhaps not related, but which driver version are you using?

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

Modutil reports that the PKCS#11 module has 
Default Mechanism Flags: RSA:DES

I wonder how that happened.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Eddy, in answer to your question in comment 2, modutil reports:

Name: eToken
Library file: eTPKCS11.DLL
Manufacturer: Aladdin Ltd.
Description: eToken PKCS#11
PKCS #11 Version 2.1
Library Version: 4.0
Cipher Enable Flags: None
Default Mechanism Flags: RSA:DES

Windows reports for that file:
File Version   4.0.43.0

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

The command
modutil -dbdir "$DBDIR" -undefault eToken -mechanisms RSA:DES
reported it had succeeded, and then crashed.  :( 
Probably a strict reference count assertion botch.
It does appear to have succeeded.

Comment 6

[Eddy Nigg (StartCom)]

/Nelson is getting updated drivers/ (just in case)

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

OK, using modutil, I removed the "default mechanism flags" from this module,
and that cured this problem.  Although I do not recall having set those 
flags, I still think it is a very likely explanation that I did so, and have
merely forgotten it.  :)  

I'm willing to reject this bug report as invalid.  It's no fault of NSS if 
the user (me) sets the default mechanism flags badly.  :)  

But I still think that bug 444974 may conceivably have a similar cause.  
I will ask the reporters of that bug to test this hypothesis with modutil.