certutil -K incorrectly reports ec private key as an orphan

RESOLVED FIXED in 3.12.3

Status

NSS
Tools
P2
normal
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: Momcilo Majic, Assigned: Nelson Bolyard (seldom reads bugmail))

Tracking

3.11.9
3.12.3
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

9 years ago
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
(Reporter)

Comment 1

9 years ago
Created attachment 335687 [details]
Certificate request, keys, root certificate and resulting certificate
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 }
Created attachment 350541 [details] [diff] [review]
patch v1 (checked in on trunk)

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)

Updated

9 years ago
Attachment #350541 - Flags: review?(julien.pierre.boogz) → review+
(Assignee)

Updated

9 years ago
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
(Assignee)

Updated

9 years ago
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
Last Resolved: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.