Unable to import PKCS12 files that could by imported with 3.3.1 version into a
Message: PKCS12 decode import bags failed: Unable to import
I will send you the P12 file
Created attachment 76341 [details]
P12 File - Password: Pass-123
The Password for the P12 is:
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
If you need it, I can provide tests p12.
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]
Password for the P12 files are 1234abC! . These are all demo certs without
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.
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.
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
firstname.lastname@example.org - 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.