460753 - PKCS12 import friendly name problem

Status: RESOLVED INVALID

(Core :: Security: PSM, defect)

Description

[Varga Viktor]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; hu; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; hu; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3

After importing 4 certificate with keys, the friendly name was not correct.
The first import name was added as friendly name to the others.
(These are openssl generated test certificates.)

Reproducible: Always

Steps to Reproduce:
1. Import the attached files into the Firefox.
2. Check the freindly name of the certificate
Actual Results:  
With this yo cant select the later imported certificate for f.e. a form singning.

Expected Results:  
Friendly name should be correct.

Comment 1

[Varga Viktor]

Attachment: test certificate files

pkcs12 files in a zip file, no password

Comment 2

[Varga Viktor]

this off-course affects the Thunderbird too...
try to import those certificates...

Comment 3

[Varga Viktor]

applies to seamonkey actual version too...
seems to bea common problem.

Comment 4

[mad_bugzilla]

I can corroborate the bug with a proper certificate issued by a registered CA.

If you import a certificate from your CA into FF for the first time, everything is peachy and FF uses the CN as the friendly name. If you then add another cert with the same CN, FF uses "CN's O Identity #2" as a friendly name. The bug basically happens after the next cert, which is also called "CN's O Idendity #2". 

In the case:

CERT #1 (friendlyName=CN)
CERT #2 (friendlyName=CN's O Identity #2)
CERT #3 (friendlyName=CN's O Identity #2)

You will be offered CERT #1 and whatever CERT of #2 or #3 is passing the sorting.

The wrong naming of the friendly names persists even if you delete the certs. You need to delete the cert8.db to get rid of the bug.

Comment 5

[mad_bugzilla]

I forgot to mention...

FF 3.5.6
TB 3.0
TB 2.0.0.22 with S/MIME Security for Multiple Identities 0.3.0

Comment 6

[Kai Engert [:KaiE:]]

I don't understand:

- why is it a bug to use those friendly names? what exactly is "wrong" with them?

- what exactly happens when you attempt to do form signing? Assuming all 4 certs have each a unique {issuer, serial number}, then your form signing prompt should contain a list of all certs.

(Should you have duplicate {issuer, serial number} pairs, then that's your bug.)

I own multiple personal certs, with friendly names in the style you have described. In Thunderbird, I can go to account settings, security, ask to pick a cert for signing, and I get a prompt that offers all 4 certs for selection.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

The 4 PKCS12 files in the attached zip file each contain a user certificate
with a subject name that is:
E=[e-mail],
CN=Varga Viktor,
OU=Teszteles,
O=Netlock Teszt tanusitvany,
L=Budapest,
C=HU

By design, and by definition, in an NSS pure software virtual token, all 
certificates with the same exact subject name MUST have the same CKA_LABEL
attribute (the same "nickname" or "friendly name").  So, when they are 
imported, if a certificate has the same subject name as a certificate that
has already been previously imported, it will be given the same nickname 
as that already imported certificate, regardless of whatever nickname it 
may have had in the PKCS12 file from which it was imported.  

This is correct behavior of NSS's pure software virtual token, and has been
since it was first designed many years ago.  Many people often find it 
surprising, and complain that it is a bug, because it is not what they 
expect, but it is exactly as designed.  

So, the "bug" reported in comment 0 is not a bug, in my opinion.

The situation reported in comment 4 is obviously different, and was produced 
under different circumstances than comment 0.  It should have been filed 
as a separate bug, because it is so different.  In comment 0, the complaint
is that all the certs were given the same identical nickname when they were
imported.  In comment 4, the complaint is that they were given nicknames 
that are all different, but similar, differing only in the suffix (e.g. #2 
or #3, etc.).  This behavior is the result of a "nickname collision".  

The same design of NSS's pure software virtual token that requires that all 
certificates with the same exact subject name have the same nickname also 
requires that no two certificates with different subject names may have the
same exact nickname.  

When an attempt is made to import a cert with a nickname that is already in 
use by another cert that is already imported into the token, a cert with a 
different subject name than the cert now being imported, this situation is
called a "nickname collision".  It is resolved by appending (or changing) 
a number on the end of the nickname (e.g. adding #2, or #3, etc.) to make
each unique subject name have a unique nickname.  

Both of these behaviors are working as designed and intended and are not bugs.

Comment 8

[Varga Viktor]

As i mentioned originaly in comment 0 it caused to me to impossible to selec certificate other than the first, for example for form signing.

At that time for testing i used the Netscape fomr signing functions.

I will check it again...