joshuaaa wrote:

> 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? 

The nickname is a component in the PKCS12 file.  Each cert potentially
has its own "friendly name" (nickname) in the pkcs12 file.  When you
import a PKCS12 file, NSS uses the nickname in the file.  When you export
one or more certs into a PKCS#12 file, it's up to the software that
creates the file to put nicknames into it.  NSS puts the nicknames it
already has for the certs into the file.

> If I import a certificate via the certificate manager, what does it assign
> for the nickname value?

When you import a "bare" certificate using PSM's certificate manager,
PSM itself derives a nickname from the cert's subject name.  I don't know
the exact algorithm.  I think it comes from the O and OU attributes, if any.

> Here's a code snippet for how I think this *should* work:
[snipped]
I can't help you with that.

> 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. 

Yes.  That imports a "bare" cert (binary or PEM).  The private key
should (must?) be present in some local token already.

> 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. 

That's what I would have suspected.  If I recall correctly, in another (?)
recent thread in this group, someone reported that they tried importing a
user cert for which the private key was not present and it silently failed.
(Or was that this thread?)  I certainly didn't expect that.

> I'm assuming that this is by design, 
Yes. This method of importing user certs is intended to be used in the
common case where a user has just requested a certificate (and in so
doing generated a key pair, leaving the private key in a local token)
and is now downloading his just-issued cert for that private key.

Years ago, in Netscape Navigator 3, this would display a dialog asking
the user to enter a nickname for his new cert.  But we found that users
were no good at picking nicknames, because they didn't understand what
the nickname was intended to differentiate.  Users always used "My cert",
which was OK for the first cert, but no good for the second one (typically).
It never occurred to users to use names like "My Verisign Cert" or
"My Thawte cert" or "My Verisign cert for [EMAIL PROTECTED]".  So,
eventually that dialog was dropped and PSM began to create its own
nicknames.  That has worked pretty well for certs from real CAs.
As far as I can recall, it's only been a problem for certs issued by
OpenSSL users, who don't put enough info into the cert's names to be
distinguished names.
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Reply via email to