1087393 - NSS: pk12util weirdness when importing 2 certs with the same DN

Status: UNCONFIRMED

(NSS :: Tools, defect, P5)

Description

[Martin Wilck]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0
Build ID: 20140918134209

Steps to reproduce:

nss-3.17.2-1.fc20.x86_64 (Fedora 20). Latest SVN is also affected (checked by reading the code).

Create 2 different certificates with the same DN (I know this is unusual, but our company CA does it). Import both certificates into a NSS db using pk12util.



Actual results:

Both certificates are successfully imported, but they will both have the same nickname (the nickname which was used for the first import). This makes it impossible to select one of them for further processing and/or deletion.

[martin@pdbcooper tmp]$ certutil -K -d sql:$PWD
< 0> rsa      a9eb1dec09f78585966aa4b2590a1561e5f7486e   FPR b9
< 1> rsa      337d5cce892b64a81bce644194eb96ca8001fd23   FPR b9

(Only < 1> here is actually the cert whose fingerprint starts with b9).


Expected results:

Either 1.) the 2nd import should have used the nickname provided with it, or 2.) pk12util should abort with an error saying that it can't import 2 certs with the same DN.

Comment 1

[Martin Wilck]

A similar problem happens if I import a public cert with certutil first, and then import a PKCS12 fiole with pk12util with a different cert with the same DN as the public cert. The 2nd imported cert will get the nickname of the previously imported public cert, which *does not match it*.

Comment 2

[Martin Wilck]

Attachment: PKCS12 file with 1st bogus certificate

Comment 3

[Martin Wilck]

Attachment: 2nd bogus certifcate

The password of both PKCS12 files is "1111".
The friendly names are "name of 1st cert", and "name of 2nd cert", respectively.

$ pk12util -d sql:$PWD -i pkcs12/cert\ 01.p12 
pk12util: PKCS12 IMPORT SUCCESSFUL
$ certutil -K -d sql:$PWD
< 0> rsa      2dda6757f771dda5ee99ae1e0d957fe3a6acc905   name of 1st cert
$ pk12util -d sql:$PWD -i pkcs12/cert\ 02.p12
$ certutil -K -d sql:$PWD
< 0> rsa      2dda6757f771dda5ee99ae1e0d957fe3a6acc905   name of 1st cert
< 1> rsa      43fd229cf8b7584eb19c2f7a04c7163d277a8635   name of 1st cert

=> both certs are imported with the same nickname.

[martin@pdbcooper ca]$ certutil -L -d sql:$PWD
Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI
name of 1st cert                                             u,u,u
CA - Zilch, Inc.                                             ,,   
name of 1st cert                                             u,u,u

=> this is even more confusing.

Comment 4

[Martin Wilck]

The problem happens here:
https://github.com/mozilla/gecko-dev/blob/master/security/nss/lib/pkcs12/p12d.c, line 2193ff:

    /* nickname not set in pkcs 12 bags, but a nick is already used for
     * this dn.  set the nicks in the p12 bags and finish.
     */
    if(existingDNNick) {
        sec_pkcs12_set_nickname_for_cert(cert, key, existingDNNick);
        goto loser;
    }

The comment is wrong, in my case the nickname *is* set in the pkcs12 bag, but it is discarded in favor of the exisiting nickname of a different cert that happens to have the same DN.

I can see that NSS hasn't been made for different certs with the same DN:

/* validate cert nickname such that there is a one-to-one relation
* between nicknames and dn's. we want to enforce the case that the
* nickname is non-NULL and that there is only one nickname per DN. */

However, the behavior shown here is wrong. If 2 certs with the same DN are actually not supported (why?), pk12util should refuse to import the second cert.

Btw, as I said above, our company CA creates these certs with identical DNs. They issue personal certs that expire after ~1y. People may ask for another cert before that happens, and get another cert with the same DN and overlapping periods of validity. I don't know if that's wrong, they just do it that way.