467344 - certificates are grouped incorrectly by certutil and JSS

Status: UNCONFIRMED

(NSS :: Tools, defect, P5)

Description

[David Stutzman]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4 (.NET CLR 3.5.30729)
Build Identifier: 3_11_4_RTM and 3_12_RTM

An RSA keypair is generated on the softtoken via JSS, a certificate request is created and sent to a CA, a cert comes back.  The cert is imported into the db using JSS method CryptoManager.importCertPackage(byte[], String) with 3 different nicknames.  Whichever certificate is imported first, the other 2 for the same user end up under the same nickname as shown by the following certutil output:

certutil -L -d .
cn=Saraniti.Paul.A.3684919180-Identity                       u,u,u
cn=Saraniti.Paul.A.3684919180-Identity                       u,u,u
cn=Saraniti.Paul.A.3684919180-Identity                       u,u,u

certutil -K -d .
<0> cn=Saraniti.Paul.A.3684919180-Identity
<1> cn=Saraniti.Paul.A.3684919180-Signature
<2> cn=Saraniti.Paul.A.3684919180-Encryption

Adding the -n "cn=Saraniti.Paul.A.3684919180-Identity" param yields all 3 certificates dumped out at once.

Back in the code using JSS, if I do CryptoManager.findCertByNickname(String) with either the signature or encryption nickname, I get ObjectNotFoundException.  If I do the signature first and then the other 2, then they all show up as signature with -L, if I do the encryption first, they all show up as encryption.  Either way, the key listing shows the correct information.

All 3 certificates have the same Issuer and Subject DNs, but each have a unique public key and different combinations of extensions.

I tested this with NSS 3.11.4 from nss releases FTP and also with NSS 3.12 built from source tarball from nss releases FTP using Mozilla Build.  In both cases, I'm using JSS 4.2.5 RTM.

As requested by Nelson, I tried with FIPS mode disabled and the behavior is still evident.  The attached db is not in FIPS mode and was created with NSS 3.11.4 with a blank password.

Reproducible: Always




NSS 3.12 certutil output (different test with nickname scheme changed to random #s):

certutil -L -d .

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

564928                                                       u,u,u
564928                                                       u,u,u
564928                                                       u,u,u

certutil -K -d .
< 0> rsa      7715f9edc54c9b7bfe05ba49129aa8b44eeee81e   564928
< 1> rsa      44ebd41689a943fdac4f4a16121f4cb54c70682c   708975
< 2> rsa      bd5ca796f9749cc4937bc0373aa21e3ecb50b62c   423087

Comment 1

[David Stutzman]

Attachment: key/cert db zipped

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

This bug report reveals that all 3 certs have the same exact subject name.
NSS's softoken fully intends that all certificates with the same subject
name should have the same nickname.  The intent is that NSS and the 
application that uses it will pick the right certificate from the ones
with a common subject name that is the right one for the operation being
performed.  The user should not need to understand that there are separate
certs for separate purposes, nor specify which one to use for each purpose.
NSS can find the right one, and should do so.  Asking the user to choose
one of those certs for a particular purpose just gives the user yet 
another chance to make the wrong choice.  

The think that strikes me as odd about this bug is the fact that the 
keys have nicknames (at all!) and that they're different.  
I haven't seen a nickname on a key in maybe 8 years.  I thought NSS 
had actually removed the capability to give nicknames to keys.  
For many years now, when you try to pick a key by nickname, NSS has actually 
found a cert with that nickname, and then found the key for that cert.  

But here's an example that shows keys with nicknames, nicknames that 
differ from the nicknames of their respective certs.  I'm puzzled by this.
:(

Comment 3

[David Stutzman]

Sorry for the different groupings of test output.  I was trying a bunch of different things at that point and just copied/pasted what I had at the moment.

I guess in the -K view, NSS is showing that it knows which cert goes with which key and is showing the nickname I asked for when I imported.  But in the -L view, NSS is showing that it knows all certs have the same subject name by grouping them under the same nickname which happens to be the first of the 3 that I import.

So the way forward for me and my JSS using app is to import all 3 certs with the same nickname.  Then to retrieve any of them, I call CryptoManager.findCertsByNickname(String nickname) which returns all certs with the given nickname.  Then I'll inspect them for things like the presence of the SAN extension and differences in key usage to determine which of the 3 is which.  Does that seem appropriate?

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

David, you could do the filtering of certs yourself, or you could use an
NSS function to do that for you.  Functions that do that sort of thing
include:

CERT_CheckCertUsage
CERT_FilterCertListByUsage(
CERT_FindUserCertByUsage(
CERT_FindUserCertsByUsage(

See more NSS functions that might help at:
http://mxr.mozilla.org/security/search?string=CERT_.*Usage&regexp=on&case=on&find=%5C.h%24&tree=security

Comment 5

[David Stutzman]

I think you keep missing that I'm using Java/JSS to access the db :).

JSS doesn't have the breadth of NSS functions available to it so I went ahead and implemented a method to "find" the right cert based on the type (id, sig, encrypt) that I'm looking for that inspects the extensions on the certs returned which works acceptably well for my particular application/situation.

On the topic of the bug that isn't, I knew NSS kept certs that were basically the same under the same nickname (like if you renew a cert for a server and import it), but wasn't quite sure that's the behavior that was "getting in the way" for me in this particular case.  Regardless, unless you want to pursue the key nickname thing, I'm considering this issue resolved and thanks for the assistance as usual!

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

David, I know you're using JSS.  
JSS is supposed to make the facilities of NSS available to Java. 
I guess it's nowhere near as complete as I had imagined.

I do want to get to the bottom of the key nicknames questions.

Comment 7

[Robert Relyea]

We can probably close this now. The nickname thing is exactly as NSS was designed. This was to allow users to have a single nickname for an identity and NSS picks the right cert (signing/auth/encryption) based on the usage. The main complaint is there isn't a way to access a specific certificate. That has changed a while ago now that NSS accepts pkcs11 urls in the nickname field. PKCS 11 urls allow you to access a pkcs11 object with any attribute, so you can use other attributes (like issuer S/N) to access a specific certificate. This will work in JSS because the access happens at the lowest level of NSS.