"The specified network password is not correct" exception in X509Certificate2 constructor

Question

I have a console application which loads an X509 Certificate from a byte array as follows:

var cert = new X509Certificate2(certificateContent,      // byte[]
                                password,                // string
                                X509KeyStorageFlags.PersistKeySet);

certificateContent is a byte[] representing the contents of a pfx file. This code works fine for a number of certificates I've tested. There is one certificate I'm testing, though, that causes this line to throw a CryptographicException with the message "The specified network password is not correct.", even though the password provided is correct.

The weird part is that I can use the same code in LinqPad to create a certificate from the same pfx file with the same password, and it works okay.

I've checked the call site in the console application in the debugger, and verified that the correct values are being passed in.

What could cause this constructor to throw this exception in a console app, but not in LinqPad using the same data, and work fine in both places for other certificates?

More Details

The certificates are stored in a database in Base64. The Console app reads the certificate from the DB, converts it from Base64 to a byte[], and then tries to create the X509Certificate2 object as above.

There are three certificates I've been testing with:

1. My personal Client Authentication certificate provided by my employer's CA.
2. A test certificate created by a colleague using his own self-signed CA.
3. My own test certificate created by myself using a self-signed CA.

Certificates 1 and 2 work as expected in both the console app and LinqPad.

Certificate 3 loads fine in LinqPad, but generates the error above if I try to use it in the console app.

There are two significant differences between certs 2 & 3.

1. Cert2 expires in 2016 and Cert3 expires in 2039
2. The private key associated with cert2 is 2048 bit. Cert3 is 1024 bits.

Could either of these differences result in the "specified network password is not correct" error? And why would all 3 certs work fine in LinqPad, but only 1 throw the error in the Console app?

Solution 1

In my case I had a self-signed certificate which I exported through MMC (microsoft management console) with a password. Loading this certificate went fine on my own machine (win10), but gave the exception with message "The specified network password is not correct" on a server machine (not win10).

What solved it in my case? When I exported the certificate I set a password using AES256-SHA256, but this certificate encryption was not supported on the server machine (after reading this dotnet runtime issue). When I changed it to TripleDES-SHA1 it worked fine locally and on the server as well.

Quote from the dotnet runtime issue:

WindowsCryptographicException: An internal error occurred probably means that PFXImportCertStore failed, returning null and calling SetLastError with NTE_FAIL.

Things that I'd speculate can cause it:

• The PFX was created with a different encryption password and integrity password, and the integrity password is what was provided to the constructor. But that wouldn't be the case if the same PFX file works on any Windows machine.
• The PFX was created using the PKCS12_PROTECT_TO_DOMAIN_SIDS and there's some sort of problem talking to AD on the other side. I don't think we support this kind of PFX. The PFX was generated using the guidance from https://www.rfc-editor.org/rfc/rfc7292#appendix-B, namely, to use PBES2+PBKDF2 for encrypting the private keys instead of pbeWithSHAAnd3-KeyTripleDES-CBC In this case, the PFX will open on Windows 10, but not prior versions. (At least, I think that's the behavior I recall hitting with this case). It also, IIRC, won't open on macOS.
• PKCS#12 v1.1 also talks about encrypting and/or signing a PFX using asymmetric cryptography rather than a password-based scheme. But I don't know if even Win10 supports that, since I don't see any controls for it in PFXExportCertStoreEx. So the only thing that I can quickly think of that makes sense is you have a "new" PFX and your test environment is Windows 10, but your production environment is Win2012R2.

Solution 2

Hopefully this will help somebody:

User "S C" points out the following requirement for certificate passwords on Windows XP and Windows Server 2003.

0 < password.Length < 32

I have seen conflicting reports on whether 32 is allowed. I can confirm that I was using a 32 character password (an MD5 hash), and truncating it to 30 characters fixed the issue.