[EMAIL PROTECTED] wrote: > Hi, Welcome to mozilla.dev.tech.crypto, Martin.
> I have tried a number of things to make Thunderbird import a > certificate and key, with no success. Originally it was in PKCS12 > format, issued by my organization as my personal certificate. Whenever > I try to import it, I get the error message "The certificate and > private key already exist on the security device" (which was definitely > not true - it even failed with an empty certificate db). There is a known bug in NSS that has this effect: if an attempt to import a cert & private key from a pkcs12 file fails to import any certs or keys, then it reports the error message you saw. That will be fixed in NSS 3.12. The question then is: why did it fail to import any certs or keys? The most common reason is: the cert associated with the private key had no "friendly name" associated with it. friendly names are optional in windows but required by NSS. If the PKCS12 file was created without a friendly name for the cert, that's why it failed. pk12util has a -l (ell, for "list") option that lists the contents of a pkcs12 file and tells you what friendly names it finds. If you run it on your pkcs12 file and find there is no nickname for that cert, that explains it. A second reason is: the cert contained one or more critical extensions that are unknown to NSS. However, based on your report (below), I think that is not the problem in your case. > The certificate was made for signing and came together with another > certificate (made for encryption) with which I had no problems. Do you mean in the same pkcs#12 file, or were they in separate files? > In the same package, I also got two CA certs in pkcs12 format which I also > imported happily. > > I then converted the certificate to PEM format with openssl. Trying to > import the PEM cert with thunderbird generated no error message, but > still the imported certificate showed up nowhere. certutil -L also > didn't list it. > > Importing the cert into the db with certutil -i, however, worked as far > as certutil itself was concerned (the cert showed up afterwards with > certutil -L). Your pkcs12 file contains a cert and a private key, and you need to import both to be able to use your cert. When you converted to PEM, and imported with certutil -i, you only imported the cert, not the private key. I'm curious to know what friendly name (a.k.a. nickname) the cert had in the output of certutil -l. > But in the thunderbird certificate manager, the imported > certificate still wouldn't show up, neither under "personal > certificates" nor anywhere else. There is a known bug in certificate manager. It has been known a long time and the fix is known, but it continues to be unfixed. Don't ask me why. (sigh) Cert manager tries to figure out which of its 4 tabs a certificate should be displayed in. It may conclude that the cert doesn't belong in any of the 4 tabs, in which case the cert simply goes undisplayed. A browser or Thunderbird user cannot really tell whether the cert is absent from his cert DB, or simply isn't being displayed. certutil does better at showing you a complete list. > Looking at the certificates with "openssl x509" I found no indication > of anything being wrong with it (but really judging that exceeds my > level of expertise). The only noteworthy thing is that the certificate > was originally generated for import with the CryptoEx Outlook plugin, > and made for signing only: > > X509v3 extensions: > X509v3 Key Usage: critical > Digital Signature > X509v3 Subject Alternative Name: > email:[EMAIL PROTECTED] > X509v3 Extended Key Usage: critical > E-mail Protection, 1.3.6.1.4.1.311.10.3.12 NSS understands all those extensions. There are no unknown critical extensions in that list. > I tried different thunderbird versions, latest was 1.5.0.8, with no > difference. > I'd appreciate any suggestions. Suggestion: re-create the PKCS12 file so that the cert has a friendly name. If it was exported from Windows' cert store, then go into the cert store, give the cert a friendly name, and then re-export it. Let us know how it goes. -- Nelson B _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
