Unable to import PKCS12 files that could by imported with 3.3.1 version into a NSS database. Message: PKCS12 decode import bags failed: Unable to import Code: -8099 I will send you the P12 file
Created attachment 76341 [details] P12 File - Password: Pass-123 The Password for the P12 is: Pass-123
Assigned the bug to Bob.
perhaps related to 128586 ?
The P12 file was generated via Baltimore's UNICERT product. I have done some more investigation it appears that NSS decodes the P12 correctly but has some problem in adding the Private Key. We have found that some P12 files generated from UNICERT do seem to work, and some fail due to this problem. I can attach a P12 file that does work and imports successfully. This is a serious problem for us - I hope you can fix this or at least point us in the right direction. These P12 file could be imported with NSS 3.1.1
I have the same problem. We are using Baltimore and Certificates generated from WebRAO or RAO as P12 files can't in general be imported in Mozilla while it work well with Communicator/MIE/openssl. But it is not limited to Baltimore: I can't import certificate exported from W2K/MIE6 either. If you need it, I can provide tests p12. Marc
If you know how to build NSS yourself, could you apply Bob Relyea's patch in bug 128586 (attachment 78489 [details] [diff] [review]) and see if it fixes this problem? Mr. Marc Jadoul, yes, if you could provide test p12 files, that would be helpful.
Created attachment 78726 [details] Demo P12 Password for the P12 files are 1234abC! . These are all demo certs without any values. There are several type of P12: some issued with Unicert RAO 3.5.3 wich is a a C application. Some other where issued from the WebRAO 2.3, a java plugin. Some are exported from MIE6. Certificates are issued from different CA too. I included 2 P7C containing the chains. One of the cert is from GlobalSign for which the root is already in Mozilla. Of course the chains should also be in p12. Then, certificates are with different Key Usage: N or Normalised for encryption and Q or Qualified for Signing. I hope it help. If you need P12 with certs having specific content (KU, emails...) it is also possible. Marc
In Response to Comment #6 - applied patch to version 3.4.1 RC1, but it did not fix the problem
Changed the QA contact to Bishakha.
Created attachment 82063 [details] [diff] [review] Fix bugs in RSA_KeyCheck() So the basic problem: NSS 3.4 introduced a security feature in which it checks the validity of the RSA private key components whenever such a key is generated or imported into the software token. This check required p > q, and if it wasn't, we would swap the p and q values. this automatically makes the coefficient wrong since its the inverse of q mod p. We are still investigating the requirement of p > q, but it doesn't affect the import because certain calculated values can be re-calculated as long as p, q, m, d, and e (prime1, prime2, modulus, private exponent, and public exponent) are correct. Unfortunately the code was failing when trying to recalculate these values. This patch fixes those failures, and now these pkcs12 files can be imported into the softoken. (Ironically, these keys would have succeeded if the were imported into a different token, because the RSA_PrivateKeyCheck() would have been bypassed).
This patch is check into the NSS tip.
Set target milestone to 3.4.2. Bob, please also check in this fix on the NSS_3_4_BRANCH. Thanks!
Bob, please also check in the patch in bug 128586 (attachment 78489 [details] [diff] [review]) on the NSS_3_4_BRANCH. Thanks.
Comment on attachment 82063 [details] [diff] [review] Fix bugs in RSA_KeyCheck() Ian, could you review this patch? Thanks.
I believe thie patch above is correct, so r=nelsonb. But I would also propose that we change the key check code with respect to when it swaps p with q. I'd propose that, if p < q but all the tests pass, then we should not swap p and q. I'd propose that we only swap p with q (and d_p with d_q) when the p < q; all the tests on n, p, q, d and e pass; but one or more of the values d_p, d_q, or qInv is found to be wrong. In that case, I'd propose that we swap p with q, and d_p with d_q, and then recompute any of d_p, d_q and qInv as needed. But this proposal is merely an efficiency enhancement, not P1.
I have tested the Patch and it works fine !
Thanks for verifying the bug fix, Mr. Brittliff. Marked the bug fixed.
adt1.0.1+ (on ADT's behalf) for checkin to the 1.0 branch. Pls check this in asap. thanks!
email@example.com - can you verify this bug fix in 1.01 branch? When verified, pls replace fixed1.0.1 keyword with verified1.0.1. Thanks.
Verified - Been fixed for a while.