Closed Bug 128586 Opened 23 years ago Closed 23 years ago

Can't restore cert exported by IE

Categories

(NSS :: Libraries, defect, P1)

Product:
NSS
Component:
Libraries
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: xenite, Assigned: KaiE)

References

Details

(Keywords: regression, Whiteboard: [adt1 RTM])

Attachments

(1 file)

Decode Attributes on keys.
2.21 KB, patch
jesup
: approval+
Details | Diff | Splinter Review
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8+) Gecko/20020301 BuildID: 20020301 I tried to import my new certificate that I renewed using IE 6.0 (I first tried to use Mozilla to renew the certificate but that failed because my ISP's website (T-Online) told me that I need to use a _new_ public key). After I had exported the new key (including the private key of course) I tried to restore it in Mozilla. When trying to restore my key, Mozilla told me that it "failed to restore the PKCS # 12 file for unknown reasons." After temporarily going back to Mozilla 0.9.8 I was able to successfully restore my certificate. Reproducible: Always Steps to Reproduce: 1. Try to import your e-mail certificate. Actual Results: Mozilla failed to restore the certificate Expected Results: Mozilla should have restored the certificate
-> PSM
Assignee: mstoltz → ssaux
Component: Security: General → Client Library
Product: Browser → PSM
QA Contact: bsharma → junruh
Version: other → unspecified
also seeing this on linux:2002030414 (os->all). i considered it my mistake, but using 0.9.8 as the reporter suggested worked for me as well.
Keywords: nsbeta1+
Priority: -- → P1
Target Milestone: --- → 2.2
Can't reproduce using win2k 2002030403. QA can this be tested on other platforms? Reporters. How were these p12 files created?
Keywords: nsbeta1+
created my .p12 via freemail.web.de. unfortunately, this option is only available to verified members, so it's probably not easily available to developers.
I do have an account at freemail.web.de. Assigning to me.
Assignee: ssaux → kaie
confirming based on Lars' comments.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Confirming the bug on two W2K systems using 0.99. P12 files were created using Secude PSE 2.2 and a company-issued certificate.
Reverting back to 0.98 on two systems did not help (see my previous posting for other details). One of the systems did not have another certificate installed before. On the other system, I was able to export the existing certificate from Mozilla and re-import it again successfully. But it does not work for certificates created by Secude.
(since this bug is still marked windows 2000: i'm on linux, currently with 0.9.9) i havent used personal certificates prior to this experience, but here are my observations: the reported error matches the one i get when importing a verisign trial certificate (followed a link somewhere at mozilla.org iirc...) and enter a correct master password and a bogus certificate password (or abort the _master_ password entry - cancelling the certificate password dialog does not return an errormessage). using the verisign cert (which accidentally uses the same passphrase as the master password) i can restore and delete however i choose to, so my setup seems to be correct - although at times deleting it (the last certificate installed) will not refresh the window correctly, still listing the deleted cert with its previous status. my freemail passphrase differs - no errormessage until after i entered it, though. hope that helps...
could this one be related to my bug 129818, which is marked WORKSFORME ? (although it still does not WORK FOR ME)
I did some further testing and this is what I found out: I used Mozilla 0.9.9 to export my certificate to a .p12 file and created a new Mozilla profile. I was still not able to import the original certificate (exported by IE 6.0 - I chose Microsoft's Enhanced Cryptographic Provider 1.00 when renewing the certificate) as expected, but I was able to import the certificate that I just backed up with Mozilla, without any problems. Then I tried to import the certificate that Mozilla previously was not able to restore and this time Mozilla didn't give me any error-message! According to Mozilla my certificate can be used for the purpose "Client, Server, Sign, Encrypt", just in case that it matters.
Tried the procedure described by Steffen, but no success.
Workaround: I was able to import the certificate after downgrading to 0.95. It seems that the bug was introduces in the meantime. Workaround confirmed on NT4 and W2K.
Confirming the bug on Win XP and Mozilla 0.9.9. Certificates where from Thawte Personal Freemail, exported to P12 from MS IE 6.0. Same files successfully restored on Debian Woody and M0.9.8.
This seems like a serious regression to me. nominating.
Keywords: nsbeta1
I'm able to restore a thawte 2k bit certificate after creating a new profile and using a recent build (2002032003). Can restore an AOL corporate cert (1Kbit). Reporter, can you try a newer daily build, on a new profile. NSS has changed since this bug was reported. If you do have a problem doing this, then we can assume that it's the interaction of the kind of p12 you're using with moz that's creating the problem. Kai, if you can try with a freemail.de p12 cert, that would help.
Still unable to restore my Secude certificate after installing build 2002032503 and creating a new profile on Win2K (failed for unknown reasons).
according to stephane's suggestions i downloaded build 2002032521/linux. i still see the same errormessage with my previous profile as well as with a newly created one when trying to import freemail.web.de's p12 cert
I tried it with the latest build 20020326-10 and Mozilla still gives me the same old errormessage when I try to import the certificate I exported from IE 6.0. Mozilla successfully imports the same certificate, if the file was exported by Mozillla and not IE 6.0, so it looks like Mozilla might have problems parsing the datastructure of the PFX file if it was written by IE.
Changing summary. This is a regression from Mozilla 0.9.8 to 0.9.9.
Keywords: regression
Summary: Mozilla can't restore my certificate → Can't restore cert exported by IE
Version: unspecified → 2.2
Ok. nsbeta1+ We'll try and get it in.
Keywords: nsbeta1 → nsbeta1+
I can reproduce the import problem with my cert from freemail.de execution path: sec_pkcs12_install_bags sec_pkcs12_add_key case SEC_OID_PKCS12_V1_PKCS8_SHROUDED_KEY_BAG_ID: PK11_ImportEncryptedPrivateKeyInfo PK11_MapPBEMechanismToCryptoMechanism PK11_UnwrapPrivKey returns 0 cryptoMech.mechanism: 310 mechanism: 936 faulty3DES: 0
got the same bug but more: In 0.98, using certificates works: restore, crl, etc. Installed 0.99, access "manage certificates" or "manage crl" would crash the browser. Reported as Bug 130518 and got the hint to use a new profile. With new profile, (build 20020326) it does not crash but import certificates from pfx does not work "failed to restore PKCS #12 file for unknown reasons". However, importing from p12 file works. Now the new problem: I can only import 2 certificates. Adding new certificates got message "Successfully restored your security certificate(s) and private key(s)" but the certificate does not show up on the list. The certificates are generated at www.swisssign.com (it is free so everyone can try). They worked with 0.98, and still working with IE, Outlook.
*** Bug 134671 has been marked as a duplicate of this bug. ***
*** Bug 135845 has been marked as a duplicate of this bug. ***
Bob, do you have an idea what could go wrong on import? This bug is NOT restricted to certs coming from IE. I am able to import the p12 using a Mozilla 0.9.4 based build, so I know for sure I know the p12 file's password. Please see some trace results in comment #22. Please let me know if you need more input from me.
From the descriptions, I'm about 80% sure it's a problem in one of the NSS 3.4 PBE algorithms. our PKCS #11 uses one set of PBE algorithms, out database uses another and .pfx files use a third. All three are valid to include in a PKCS #12 file, and I suspect the third didn't get tested. That's my current working assumption anyway. This problem is #2 or #3 on my list this week. bob
OS: Windows 2000 → All
Hardware: PC → All
So the problem wasn't PBE after-all. .pfx and our .p12 are using the same PBE algorithms. Microsoft is setting attributes on the private key. NSS 3.4 was not decoding the attributes, so import of .pfx files were failing. This might also fix some potential mysterious issues where keys could be read from the key database in NSS 3.3 but not NSS 3.4 (a key imported from a .pfx file with attributes may transfer those attributes to the keydb).
Thanks for the patch, Bob! I can confirm this fixes the problem, at least for all the p12 files I have. Nominating for adt1, because this is a regression that stops users from using their backed up certificates.
Keywords: adt1.0.0
Whiteboard: [adt1]
Additional note for adt: this patch is completely within NSS, so we don't need sr=.
adt1.0.0 (on ADT's behalf) approval for checkin to 1.0. Pls check it into the 1.0 branch and trunk.
Keywords: adt1.0.0 → adt1.0.0+
Note: I just sent mail to drivers, asking for approval, too. The branch that ADT mentioned is the MOZILLA_1_0_0_BRANCH, in addition we need it on NSS_CLIENT_TAG. Thanks.
Keywords: approval
Bob, last night I made available a test build for some other bug. I thought it might be helpful to also include the fix from this bug in the test build, and I did. The other bug is 119418. While your patch works perfectly for me, a user of that test build reported a strange problem: When he imported the p12 file, the cert did not appear in the "my certs" tab, but it showed up in the "other people" tab. But still, the import must have worked in some way, because the user was able to decrypt messages with that cert. The user appeared to have used a fresh profile. While the cert got imported, it does not appear to have correct attributes, i.e. PSM is unable to identify as a "own" cert, and therefore it can not be used to configure it as self's email certificate. Do you think that could be a side effect of your patch?
Comment on attachment 78489 [details] [diff] [review] Decode Attributes on keys. a=rjesup@wgate.com. Don't forget to check into trunk too.
Attachment #78489 - Flags: approval+
Although this patch seems to be completely ready, I don't want to check it in now. I saw a crash, that I reported in bug 136747, and I only see the crash with this patch applied. I'll wait until Bob had a chance to look at it.
Bug 136747 is invalid, I didn't clobber NSS.
I checked this patch in to MOZILLA_1_0_0_BRANCH. I'm not 100% percent sure what I have to do for the trunk. Is the right approach: Check it in to NSS_3_4_BRANCH and move NSS_CLIENT_TAG tag to that revision?
No, don't check it into the 3.4 BRANCH. Server only fixes are going there. It is already checked into the tip. bob
Bob, I was reluctant to move the tag to the newest version, because: Currently file keydb.c's NSS_CLIENT_TAG points to release 1.13. But the fix from your patch in this bug landed on release 1.17. I feared, if I move the tag only for the two files contained in this tag, I'll produce an inconsistency? I thought I have to avoid this by checking it in to the branch, where most of the file revisions for NSS_CLIENT_TAG live. What should I do?
When bugs are fixed on the 1.0 branhc, pls replace adt1.0.0+ with fixed1.0.0 keyword. After QA has verified the fix is in the branch, pls replace fixed1.0.0, with verified1.0.0.
Keywords: adt1.0.0+ → fixed1.0.0
John, can you please verify on the branch? Note: Not yet landed on the trunk, delayed until I know the solution for my question in comment #39.
Status: NEW → ASSIGNED
Works for me with the 4/15 branch Win2000 build. Adding verified1.0.0 keyword.
Keywords: fixed1.0.0 → verified1.0.0
please see bug #139196, which might be related but doesn't seem to be fixed by this patch
Wan-Teh landed this patch on the trunk. Marking fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Changed product to NSS.
Component: Client Library → Libraries
Product: PSM → NSS
Target Milestone: 2.2 → 3.5
Version: 2.2 → 3.4
Set target milestone to NSS 3.4.2 because the fix is also on the NSS_3_4_BRANCH.
Target Milestone: 3.5 → 3.4.2
Verified on the 5/16 Win32 trunk.
Blocks: 145836
Is this a new patch? This bug is currently marked verified1.0.0. This indicates that is was verified/fixed on the 1.0 branch. Holding off on adt1.0.1+ until we knwo the current state of this bug.
Blocks: 143047
Whiteboard: [adt1] → [adt1 RTM]
Jaime is right. This is not a new patch. Kai already checked in this patch on the MOZILLA_1_0_0_BRANCH on 2002/04/12 (see comment #37), so this bug is already fixed in Mozilla 1.0. My bad. Sorry about the confusion.
No longer blocks: 145836
Verified on branch.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: