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)
Tracking
(Not tracked)
RESOLVED
FIXED
3.12.3
People
(Reporter: momcilo, Assigned: nelson)
Details
Attachments
(2 files)
3.91 KB,
application/octet-stream
|
Details | |
820 bytes,
patch
|
julien.pierre
:
review+
|
Details | Diff | Splinter Review |
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•16 years ago
|
||
Assignee | ||
Comment 2•16 years ago
|
||
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
Assignee | ||
Comment 4•16 years ago
|
||
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 }
Assignee | ||
Comment 5•16 years ago
|
||
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•16 years ago
|
Attachment #350541 -
Flags: review?(julien.pierre.boogz) → review+
Assignee | ||
Updated•16 years ago
|
Attachment #350541 -
Attachment description: patch v1 → patch v1 (checked in on trunk)
Assignee | ||
Comment 6•16 years ago
|
||
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•16 years ago
|
Target Milestone: --- → 3.12.3
Assignee | ||
Comment 7•15 years ago
|
||
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.
Description
•