From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8+)
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
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
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.
Can't reproduce using win2k 2002030403.
QA can this be tested on other platforms?
Reporters. How were these p12 files created?
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.
confirming based on Lars' comments.
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
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
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
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
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.
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.
We'll try and get it in.
I can reproduce the import problem with my cert from freemail.de
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
*** 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
Created attachment 78489 [details] [diff] [review]
Decode Attributes on keys.
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.
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.
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.
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
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.
email@example.com. Don't forget to check into trunk too.
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
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, 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,
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.
Works for me with the 4/15 branch Win2000 build. Adding verified1.0.0 keyword.
please see bug #139196, which might be related but doesn't seem to be fixed by
Wan-Teh landed this patch on the trunk.
Changed product to NSS.
Set target milestone to NSS 3.4.2 because the fix is also
on the NSS_3_4_BRANCH.
Verified on the 5/16 Win32 trunk.
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.
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.
Verified on branch.