452391 - certutil -K incorrectly reports ec private key as an orphan

Status: RESOLVED FIXED

(NSS :: Tools, defect, P2)

Description

[Momcilo Majic]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: 3.12

Creating request with certutil -R and importing resulting certificate certutil -A can leave private key marked as orphan.

The Root CA was established ejbca. It is interesting to note that ejbca did return signed certificate without some of the fields from DN specified in a request. Is this causing the orphan status of the key when certificate is imported?

Reproducible: Always

Steps to Reproduce:
I have created simple CA using ejbca. The root certificate is ECDSA based.

1. Than I've tried to create certificate request using certutil:
certutil -R -s "CN=Vlatacom CSCA,O=Vlatacom,C=SR" -o request.req -a -d database -k ec -q prime1921 -a
2. I've uploaded resulting request to the EJBCA, signing and got cert.pem
3. I've imported the resulting certificate
4. Listing the keys still designates only one ec key with status orphan

Comment 1

[Momcilo Majic]

Attachment: Certificate request, keys, root certificate and resulting certificate

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Using the .db files in the attached zip file, we see these contradictory 
results:

# certutil -L -d /tmp/452391a
Vlatacom CSCA                                                CT,C,c
DSECDSA                                                      Pu,Pu,Pu

# certutil -K -d /tmp/452391a
< 0> ec       818496a9e24cdc5a1c246f7f7ef182b672c01443   (orphan)

Clearly, certutil -L finds that it can match a private key to the cert.
There is only one private key, so it must be the one that matches the cert,
but certutil -K doesn't match it, and instead reports an orphan.

This is probably a library bug, not a tools bug.  That is, the fault is 
probably not in certutil, but rather in libNSS3 or libsoftokn3.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

Same result with latest 3.11.x and 3.12.x.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

I just found a bug in certutil.  I suspect it is the cause of the behavior 
reported in this bug report.  

 990 if (!keyName || !keyName[0]) {  
 991     /* Try extra hard to find nicknames for keys that lack them. */  
 992     CERTCertificate * cert;  
 993     PORT_Free((void *)keyName);  
 994     keyName = NULL;  
 995     cert = PK11_GetCertFromPrivateKey(node->key);  
 996     if (cert) {  
 997         if (cert->nickname && !cert->nickname[0]) {  
                                   ^ should not be there   ************
 998             keyName = PORT_Strdup(cert->nickname);  
 999         } else if (cert->emailAddr && cert->emailAddr[0]) { 
1000             keyName = PORT_Strdup(cert->emailAddr); 
1001         } 
1002         CERT_DestroyCertificate(cert); 
1003     } 
1004 }

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

Attachment: patch v1 (checked in on trunk)

This one character patch greatly improves the results I get.
Julien, please review.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 350541 [details] [diff] [review]
patch v1 (checked in on trunk)

Checking in certutil.c; new revision: 1.144; previous revision: 1.143

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

I'm marking this as resolved/fixed.
It should be reopened if the problem is found to persist.