How can constructing an X509Certificate2 from a PKCS#12 byte array throw CryptographicException(“The system cannot find the file specified.”)?

Question

I\'m trying to construct an X509Certificate2 from a PKCS#12 blob in a byte array and getting a rather puzzling error. This code is running in a desktop applica

Answer 1

Do you have PKCS#12 or just PFX-file? In the Microsoft world it is the same, but other think another (see this archived page).

You can try just following

X509Certificate2 cert = X509Certificate2(byte[] rawData, "password");
X509Certificate2 cert2 = X509Certificate2(byte[] rawData, "password",
              X509KeyStorageFlags.MachineKeySet |
              X509KeyStorageFlags.PersistKeySet |
              X509KeyStorageFlags.Exportable);

(X509Certificate2(Byte[])) or

X509Certificate2 cert = X509Certificate2("C:\Path\my.pfx", "password");

(see X509Certificate2(String, String) and Import(String, String, X509KeyStorageFlags) on Microsoft Docs if you need use some flags)

UPDATED: It would be helpful if you insert a code fragment and not only the exception stack trace.

Which X509KeyStorageFlags do you use? You can use Process Monitor to find out which file could not find the X509Certificate2 constructor. It can be for example that there are no default key container for the current user on the Windows XP having the problem. You can create it and retry the import.

Answer 2

I had this same problem.

1. Open IIS on the server hosting the site.
2. Find the application pool for the site.
3. Click Advanced Settings.
4. Change "Load User Profile" to true. (may require restart or reboot)

This allows the crypto subsystem to work.

Answer 3

Running into this in an web application on Windows 2012, Setting application pool option Load User Profile to true made it work.

To do this, run inetmgr.exe, go to Advanced Settings for the right application pool, change Load User Profile under Process Model to true.

Answer 4

I had exactly the same problem. The same code and data/certs ran fine on Windows 2003 x86 when running under a specific user, but failed under another account (which was also used for running IIS app pools).

Apparently, some other thing exhausted resources on Windows, so that the failing user could not really load the user's profile (his desktop was weird-looking), although there were no related events in Event Viewer.

A reboot solved the problem temporarily. Although this is no permanent solution to the problem, it shows that there's something else (eg, COM+ components, native code services, etc) consuming resources that needs to be investigated. It also shows the instability of Windows platforms...

Answer 5

I ran into the same issue.

According to this old KB article the problem was that the constructor tries to load the cert into the current user's profile, but the .Net code I was impersonating the user and so it had not loaded the user profile. The constructor requires the loaded user profile to work properly.

From the article:

The X509Certificate2 class constructors attempt to import the certificate into the user profile of the user account that the application runs in. Many times, ASP.NET and COM+ applications impersonate clients. When they do, they do not load the user profiles for the impersonated user for performance reasons. So, they cannot access the "User" certificate store for the impersonated user.

Loading the user profile fixed the error.