Hi,
This may not be exactly the same issue, but today I saw a problem with
openssl 0.9.7d, PKCS12, and long passwords. Specifically I tried using
a 128 character import password on a PKCS12 file and found that I
couldn't parse the PKCS12 file using PKCS12_parse. The same certificate
with a 20 or 32 character password run through the same program worked
fine. I was also able to parse the certificate with a 128 char password
using the openssl command line.
Here is the gist of the program:
FILE *fp;
EVP_PKEY *pkey;
X509 *cert;
STACK_OF(X509) *ca = NULL;
// ...init fp and password...
PKCS12 *p12 = d2i_PKCS12_fp(fp, NULL);
if (!p12) {
fprintf(stderr, "Error reading PKCS#12 file\n");
ERR_print_errors_fp(stderr);
exit(1);
}
if (!PKCS12_parse(p12, password, &pkey, &cert, &ca)) {
fprintf(stderr, "Error parsing PKCS#12 file\n");
ERR_print_errors_fp(stderr);
exit(1);
}
On the file with the long password this program fails with the following
error:
Error parsing PKCS#12 file
31389:error:23076071:PKCS12 routines:PKCS12_parse:mac verify
failure:p12_kiss.c:121:
So either I'm using openssl incorrectly (entirely possible) or there is
a bug in the APIs. Below is a set of steps to reproduce the program. I
can send tarball of the certificate files and source to anyone who is
interested.
1. Created a test CA using CA.pl
2. Issued a certificate, pwtest_cert-4.pem, password test.
3. Converted the PEM file to pkcs12, pwtest_cert-4.p12
4. Created three PKCS12 files with passwords of length 20, 32, and 128
characters. The cert files are pwtest_cert-20.p12, pwtest_cert-32.p12,
and pwtest_cert-128.p12 respectively. This is a little convoluted, but
I used these commands for creating pkcs12 files with specific passwords:
$ openssl pkcs12 -in pwtest_cert-4.p12 -out temporary.pem
$ openssl pkcs12 -in temporary.pem -out pwtest_cert-XXX.p12 -export
For the second command I used the appropriate password and file name.
5. Use pkcs12_parse (my own program, described above) which calls the
PKCS12_parse function using the file and password data. Note that the
128 character password has a mac verify failure.
$ ./pkcs12_parse
Usage: ./pkcs12_parse <pkcs12 file> [password]
$ pkcs12_parse ../pwtest_cert-20.p12 12345678901234567890
pkcs12_parse: PASSED
$ pkcs12_parse ../pwtest_cert-32.p12 12345678901234567890123456789012
pkcs12_parse: PASSED
$ pkcs12_parse ../pwtest_cert-128.p12
123456789012345678901234567890123456789012345678901234567890123456789012
34567890123456789012345678901234567890123456789012345678
Error parsing PKCS#12 file
31389:error:23076071:PKCS12 routines:PKCS12_parse:mac verify
failure:p12_kiss.c:121:
6. However using command line openssl I can parse the 128 char password
certificate, e.g.
$ openssl pkcs12 -in pwtest_cert-128.p12 -info -noout
Enter Import Password:
MAC Iteration 2048
MAC verified OK
PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048
Certificate bag
PKCS7 Data
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048
As I said above, I can send tarball of the certificate files and source
to anyone who is interested.
Steven
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Deane Sloan
> Sent: Monday, November 08, 2004 12:54 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: PKCS12 password >=32 chars interop issue with
> Microsoft cert stor es?
>
>
> Hi Stephen,
>
> A quick run under Netscape 4.74 (all I had around I'm sorry)
> shows a similar problem with longer passwords - pkcs12 export
> from MS (regardless of "Enable strong protection" option) or
> Netscape with long password won't import into the other.
>
> I'll test with the newer Mozilla variants - however at this
> point it's beginning to look like a point of difference.
>
> Unfortunately, removing the mac isn't too palatable for our
> usage - we need to export a PKCS12 that is of a similar
> "quality" to that exported by IE/user store. We also need to
> be able to support importing from a pkcs12 exported from
> IE/user store and correctly verify it.
>
> Regardless of the politics around the dominance of IE, this
> problem could be said to extend to anything reliant upon the
> CyptoAPI and the PFXExportCertStoreEx, PfxImportCertStore
> and PFXVerifyPassword functions - including Windows itself.
>
> Is there a possibility that a compatibility option (if not a
> #define) might surface in future versions of OpenSSL? With
> the steady shift from passwords to pass phrases, this issue
> is likely to become relevant to a larger number of users.
>
> On the face of it, what issues do you see with using the code
> below (aside from breaking from a supported OpenSSL distro
> etc) to achieve the desired compatibility?
>
> Best regards,
>
> Deane Sloan
>
> -----Original Message-----
> From: Dr. Stephen Henson
> To: [EMAIL PROTECTED]
> Sent: 9/11/2004 8:49 AM
> Subject: Re: PKCS12 password >=32 chars interop issue with
> Microsoft cert stor es?
>
> On Mon, Nov 08, 2004, Deane Sloan wrote:
>
> > Hi,
> >
> > We are using the OpenSSL PKCS#12 features for creating files for
> import
> > to/from the Microsoft user stores - using PKCS12_parse and
> PKCS12_create (
> > nid_key=NID_pbe_WithSHA1And3_Key_TripleDES_CBC,
> > nid_cert=NID_pbe_WithSHA1And40BitRC2_CBC, iter=2000, mac_iter=2000,
> > keytype=0).
> >
> > Our tests have uncovered an issue where passwords of 32
> ASCII chars or
> > larger used on either side (MS store or OpenSSL) result in neither
> system
> > reading files generated by the other due to MAC verification failure
> > (ERR_GET_LIB(...) == ERR_LIB_PKCS12 && ERR_GET_REASON(...) ==
> > PKCS12_R_MAC_VERIFY_FAILURE ) on the PKCS12_parse side and similar
> password
> > related errors on the certificate import wizard side (assuming
> > PFXVerifyPassword failure in the CryptoAPI).
> >
> > Basically - it would seem that MS's MAC generation is based on a
> maximum of
> > 32 characters (for example - try exporting from the MS user
> store with
> a
> > password greater than 32 chars, re-import the file to the store but
> only
> > supply the first 32 characters back).
> >
> > Changing the following in the PKCS12_key_gen_uni function in
> p12_key.c, line
> > 136, from:
> > if(passlen) Plen = v * ((passlen+v-1)/v);
> >
> > to:
> > if(passlen) Plen = v * ((min(passlen,0x40L)+v-1)/v);
> >
> > results in correct operation (from the *limited* testing I've
> undertaken)
> > for both import to and from OpenSSL and the MS stores - at character
> lengths
> > >= 32 ASCII chars. This has been tested against 0.9.7d - however I
> note that
> > p12_key.c hasn't changed in the 0.9.7d release.
> >
> > Is the Microsoft approach correct?
> > If not - is there possible scope for a #define option for
> users where
> MS
> > PKCS#12 interop is desirable? (apologies in advance if such
> an option
> does
> > exist)
> >
> > Best regards,
> >
>
> This is the first I've seen of this issue. The MS approach
> AFAIK is a bug. Have you tried Mozilla to see if it does the same?
>
> When you parse a file a workaround would be to use -nomacver.
> For creation there's also the (currently undocumented) -nomac
> option in OpenSSL 0.9.8.
>
> Steve.
> --
> Dr Stephen N. Henson. Email, S/MIME and PGP keys: see
> homepage OpenSSL project core developer and freelance
> consultant. Funding needed! Details on homepage.
> Homepage: http://www.drh-consultancy.demon.co.uk
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
