Closed Bug 452391 Opened 16 years ago Closed 15 years ago

certutil -K incorrectly reports ec private key as an orphan

Categories

(NSS :: Tools, defect, P2)

3.11.9
x86
Windows XP
defect

Tracking

(Not tracked)

RESOLVED FIXED
3.12.3

People

(Reporter: momcilo, Assigned: nelson)

Details

Attachments

(2 files)

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
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: cmsutil -R generating orphan key → certutil -K incorrectly reports ec private key as an orphan
Version: unspecified → 3.11.9
Same result with latest 3.11.x and 3.12.x.
Priority: -- → P2
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 }
This one character patch greatly improves the results I get.
Julien, please review.
Assignee: nobody → nelson
Status: NEW → ASSIGNED
Attachment #350541 - Flags: review?(julien.pierre.boogz)
Attachment #350541 - Flags: review?(julien.pierre.boogz) → review+
Attachment #350541 - Attachment description: patch v1 → patch v1 (checked in on trunk)
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
Target Milestone: --- → 3.12.3
I'm marking this as resolved/fixed.
It should be reopened if the problem is found to persist.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.