512926 - problem with Client certificats on etoken with same LABEL but not same subject

Status: RESOLVED WONTFIX

(NSS :: Libraries, defect, P5)

Description

[jhu]

User-Agent:       Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 1.1.4322; InfoPath.1; FDM; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Build Identifier: from 2.0 to last build 3.5

we use Aladdin etoken to store user certificats.
Each etoken usb key as 3 certificats :
 - 1 client certificat
 - 1 certificat to sign emails
 - 1 certificat to crypt emails
The 3 certificats have the same CKA_LABEL 
The 2 email certificats have the same subject
The client certificat do not have the same subject 

When we want to use the Client certificat to authenticate a user on a web site, it's works well on IE, but not on Firefox.
Firefox do not open the dialog box that list the certificats that are accepted by the web site. (IE do)
This was tested on windows and linux, with firefox version 2, 3.0, and 3.5.

If we remove the 2 emails certificats from the key, then we can authenticate on the web site with firefox and the certificat on the eToken.

There is a problem when there is an other certificat on the eToken with the samke CKA_LABEL but not the same subject.

Here what we have found by debuging firefox: (firefox 3 on linux)


function CERT_FindUserCertsByUsage
in "security/nss/lib/certhigh/certhigh.c"

This function is called to select a valid certificat for the web site

 102 CERTCertList *
 103 CERT_FindUserCertsByUsage(CERTCertDBHandle *handle,
 104                           SECCertUsage usage,
 105                           PRBool oneCertPerName,
 106                           PRBool validOnly,
 107                           void *proto_win)
 108 {
 109     CERTCertNicknames *nicknames = NULL;
 110     char **nnptr;
 111     int nn;
 112     CERTCertificate *cert = NULL;
 113     CERTCertList *certList = NULL;
 114     SECStatus rv;
 115     int64 time;
 116     CERTCertListNode *node = NULL;
 117     CERTCertListNode *freenode = NULL;
 118     int n;
 119
 120     time = PR_Now();
 121
 122     nicknames = CERT_GetCertNicknames(handle, SEC_CERT_NICKNAMES_USER,
 123                                       proto_win);

firefox get the list of nicknames (<token name>:<ident>)

 124
 125     if ( ( nicknames == NULL ) || ( nicknames->numnicknames == 0 ) ) {
 126         goto loser;
 127     }
 128
 129     nnptr = nicknames->nicknames;
 130     nn = nicknames->numnicknames;
 131

Loop on each nicknames to find certificats.
 132     while ( nn > 0 ) {
 133         cert = NULL;
 134         /* use the pk11 call so that we pick up any certs on tokens,
 135          * which may require login
 136          */
 137         if ( proto_win != NULL ) {

Firefox get one (and only one) certificat selected as 'best' for all with the same nickname.

 138             cert = PK11_FindCertFromNickname(*nnptr,proto_win);

(the 3 certificats have the same nickname)
The one choosed by PK11_FindCertFromNickname function is the last on the key. In that case, the certificat to sign email.

 139         }
 140
 141         /* Sigh, It turns out if the cert is already in the temp db, because
 142          * it's in the perm db, then the nickname lookup doesn't work.
 143          * since we already have the cert here, though, than we can just call
 144          * CERT_CreateSubjectCertList directly. For those cases where we didn't
 145          * find the cert in pkcs #11 (because we didn't have a password arg,
 146          * or because the nickname is for a peer, server, or CA cert, then we
 147          * go look the cert up.
 148          */
 149         if (cert == NULL) {
 150             cert = CERT_FindCertByNickname(handle,*nnptr);
 151         }

 152
 153         if ( cert != NULL ) {
 154            /* collect certs for this nickname, sorting them into the list */

Firefox make a list off all certificats that have the same subject that the 'best' choosed.
The 2 certificats to sign and crypt emails have the same subject
C = FR
O = company
OU = company CA1
E = [e-mail]
CN = john smith

Only the 2 email certificats are on the list.
The client certificat is not choosed.

 155             certList = CERT_CreateSubjectCertList(certList, handle,
 156                                 &cert->derSubject, time, validOnly);
 157
 158             CERT_FilterCertListForUserCerts(certList);
 159
 160             /* drop the extra reference */
 161             CERT_DestroyCertificate(cert);
 162         }
 163
 164         nnptr++;
 165         nn--;
 166     }

After, firefox filter the certificats as type SSLClient.
There is not certificat that for SSLClient usage on the list build.
==> firefox do not find the client certificat.



Reproducible: Always

Steps to Reproduce:
1. an etoken with 2 or more certificats, the last on the etoken must not be a client certificat and have a different subject that the client certificat.
2. browse a web site with certificat client authentication
3.
Actual Results:  
no dialog box that list the client certificat

Expected Results:  
a dialog box with the list of client certificats for that web site.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

NSS requires and assumes that all certificates on a token with the same 
CKA_LABEL have the same subject, and that all certificates with the same 
subject on a token have the same CKA_LABEL.  In other words, it assumes and
requires a 1-to-1 correspondence between CKA_LABEL and certificate subject 
name on any token.  This is a design characteristic of NSS. 
It was a design choice, not an accident.  It is not regarded as a bug.  

The usual complaint that we get is from a user with a token that has multiple
certs, all with the same subject name but each with different unique CKA_LABEL
strings.