Yevgeniy Gubenko wrote: > You were right about the absence of a certificate in generated with JKS > format client.private file. But unfortunately, attempt to generate the > self-signed certificate for the keystore, then converting it to PKCS12 > format (client.privatepkcs12) and finally, import it to NSS database > result with the same error.
> Here is the output I get when I use pk12util -l command, as you suggested: > pk12util -l client.privatepkcs12 > > Enter password for PKCS12 file: > Key(shrouded): > Friendly Name: acemsclientprivate > > Certificate(has private key): > [snip] > > Friendly Name: CN= cnname,OU= ouname,O= oname,L= lname,ST= stname,C= cname Wow, that's a really long Friendly name. I wonder if that's the problem. BTW, it's very odd for a directory name to have spaces in it like that. > Can you see something wrong? There are basically 3 broad classes of things that can go wrong that lead to the error you're seeing. They are: - can't find a certificate for the private key - can't import the certificate for the private key into the PKCS#11 module - can't import the private key into the PKCS#11 module The output of the pk12util list seems to eliminate the first possibility. The reasons for the latter two vary by PKCS#11 module, and sadly, pk12util doesn't even tell you the error code returned by the PKCS#11 module, nor does it even tell exactly what it was trying to do (import cert, import key) when it gets the error. The list of things that the PKCS#11 module might possibly dislike about the cert or key is long, so guessing is rather fruitless. If you have a debug build of NSS, you can enable PKCS#11 module logging and get a log of all the calls from the application to the PKCS#11 module, and the values returned by the module. For info on how to do that, see http://www.mozilla.org/projects/security/pki/nss/tech-notes/tn2.html _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
