On Aug 1, 12:43 am, Nelson B Bolyard <[EMAIL PROTECTED]> wrote:
> joshuaaa wrote:
> > However, I have not succeeded yet in importing a p12 file. When I do a
> > CertDB.ImportPKCS12File(null, cert_file);
> > it runs fine, asks for the password, I enter the password, and then I
> > get an alert that reads "Failed to restore the PKCS #12 file for
> > unknown reasons".
>
> <sigh>. The report of "unknown reasons" is a failing of PSM, the FF code
> that provides the GUI for the crypto stuff. NSS *ALWAYS* provides a
> reason. PSM just takes a shortcut and says "unknown reasons" instead of
> displaying the error string associated with the NSS error code.
> I've been trying literally for years to get PSM to report the error string
> that NSS provides for all errors, and never report "unknown reasons".
> FF3 reports Unknown Reason in fewer circumstances than FF2 did, but it
> still reports that in way too many places.
>
> If I could get Mozilla Corporation to fix one thing about PSM, it would
> be to stamp out all reports of "unknown reasons", once and for all.
>
> > I don't know if this is because the private key is not already stored
> > in a token, but that doesn't make a whole lot of sense to me, I would
> > imagine it knows what to do with the p12 file (ie get the certificate
> > and keys). Can anyone shed some light on this?
>
> NSS reported a reason. But the GUI didn't bother to pass it on to the user.
> All we can do is guess. I'm at least as frustrated about this as you are.
>
> > 2) I know that writing to the database while firefox is running is
> > bad, but is it only bad when you are adding/removing certificates?
>
> No. It's always bad.
>
> > 3) How does NSS relate a particular private key on a token to a
> > certificate? Is the process as simple as: open a p12, get the private
> > key, add private key to token, import certificate and give it
> > nickname?
>
> Almost that simple. It also checks to make sure that the pkcs12 file
> has a private key that corresponds to at least one of the certs in the
> file. If you had a p12 file with a private key and a cert, but the
> public key in the cert did not correspond to the private key, that
> would fail.
>
> > I would imagine there is more to adding the key to the token
> > than just passing the key to the token?
>
> Not much. NSS computes a "key ID" value (the PKCS#11 CKA_ID attribute)
> and puts that on both the private key and the cert as it imports them.
> The CKA_ID is computed from the public key. That way, later when the
> user says "use the private key for this cert", NSS can find the key by
> looking for a key with the right CKA_ID value.
>
>
>
> > I would like to accomplish this through the use of javascript, but jss
> > is an option if this can be done while the browser is running. If
> > anyone has done something similar, please get in touch with me.
>
> The possibilities are:
> - something wrong with the pkcs12 file (e.g. key and cert don't match,
> cert lacks a nickname, nickname conflict),
> - bug in some code
>
> I'd suggest you start by exporting a private key and cert to a PKCS12 file
> from the browser. The browser generally likes the file it makes. :)
> Then try importing that.
>
> > As always, thanks for the help.
Thanks for the info Nelson. I don't think that the p12 file could be
the problem, everything works fine if I import it manually through the
browser. It's only when I'm using the javascript to import the file
that it fails. I love firefox to death, but very disappointed in the
short comings of PSM. It's extremely frustrating knowing that there is
a problem and having no way to see where it came from or why it
occurred.
Now that I understand the process of how the nicknames work, I wonder
if I'm missing a step in my code. The importPKCS12File() function for
the XPCOM interface i'm using does not take any argument for a
nickname. Neither do the other import certificate functions... what
gives? Are they assigning the nicknames themselves? If I import a
certificate via the certificate manager, what does it assign for the
nickname value?
Here's a code snippet for how I think this *should* work:
netscape.security.PrivilegeManager.enablePrivilege('UniversalXPConnect');
netscape.security.PrivilegeManager.enablePrivilege('UniversalFileRead');
const nsX509CertDB = "@mozilla.org/security/x509certdb;1";
const nsIX509CertDB = Components.interfaces.nsIX509CertDB;
const nsLocalFile = "@mozilla.org/file/local;1";
const nsILocalFile = Components.interfaces.nsILocalFile;
var file =
Components.classes[nsLocalFile].createInstance(nsILocalFile);
file.initWithPath("path\to\cert.p12");
var db =
Components.classes[nsX509CertDB].getService(nsIX509CertDB);
db.importPKCS12File (null, file );
If anyone is wondering, the first argument for the importPKCS12File
function is the token, which can be null to mean any token. See:
http://www.xulplanet.com/references/xpcomref/ifaces/nsIX509CertDB.html#method_importPKCS12File
I've read a ton of older discussions in this group and haven't come
across anything quite like this, but I did see the importing of a
certificate using the HTTP header: Content-type:application/x-x509-
user-cert. I realize that you can't use a p12 for this (sure would be
nice though), so I used the pem and der versions of the certificate
but got an alert that told me the private key corresponding to that
cert was not in the database and therefore was not imported. I'm
assuming that this is by design, but I'm not sure how it's useful
considering that the key and cert go hand in hand. Obviously I'm
missing something there, forgive my ignorance. Nelson can you explain
this to me?
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
