Last Comment Bug 452391 - certutil -K incorrectly reports ec private key as an orphan
: certutil -K incorrectly reports ec private key as an orphan
Product: NSS
Classification: Components
Component: Tools (show other bugs)
: 3.11.9
: x86 Windows XP
: P2 normal (vote)
: 3.12.3
Assigned To: Nelson Bolyard (seldom reads bugmail)
Depends on:
  Show dependency treegraph
Reported: 2008-08-27 03:47 PDT by Momcilo Majic
Modified: 2009-02-08 16:53 PST (History)
0 users
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---

Certificate request, keys, root certificate and resulting certificate (3.91 KB, application/octet-stream)
2008-08-27 03:49 PDT, Momcilo Majic
no flags Details
patch v1 (checked in on trunk) (820 bytes, patch)
2008-11-28 17:25 PST, Nelson Bolyard (seldom reads bugmail)
julien.pierre: review+
Details | Diff | Splinter Review

Description Momcilo Majic 2008-08-27 03:47:50 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: 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 2008-08-27 03:49:58 PDT
Created attachment 335687 [details]
Certificate request, keys, root certificate and resulting certificate
Comment 2 Nelson Bolyard (seldom reads bugmail) 2008-08-27 11:32:22 PDT
Using the .db files in the attached zip file, we see these contradictory 

# 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) 2008-08-27 11:38:45 PDT
Same result with latest 3.11.x and 3.12.x.
Comment 4 Nelson Bolyard (seldom reads bugmail) 2008-11-28 17:22:36 PST
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) 2008-11-28 17:25:32 PST
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.
Comment 6 Nelson Bolyard (seldom reads bugmail) 2008-12-01 22:55:49 PST
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) 2009-02-08 16:53:05 PST
I'm marking this as resolved/fixed.
It should be reopened if the problem is found to persist.

Note You need to log in before you can comment on or make changes to this bug.