"An internal error occurred." when loading pfx file with X509Certificate2
I'm trying use self-signed certificate (c#):
X509Certificate2 cert = new X509Certificate2(
Server.MapPath("~/App_Data/myhost.pfx"), "pass");
on a shared web hosting server and I got an error:
System.Security.Cryptography.CryptographicException: An internal error occurred.
stack trace ends with
System.Security.Cryptography.CryptographicException.
ThrowCryptogaphicException(Int32 hr) +33
System.Security.Cryptography.X509Certificates.X509Utils.
_LoadCertFromFile(String fileName, IntPtr password, UInt32 dwFlags,
Boolean persistKeySet, SafeCertContextHandle& pCertCtx) +0
System.Security.Cryptography.X509Certificates.X509Certificate.
LoadCertificateFromFile(String fileName, Object password,
X509KeyStorageFlags keyStorageFlags) +237
System.Security.Cryptography.X509Certificates.X509Certificate2..ctor(
String fileName, String password) +131
On my dev machine it loads ok. The reason I load *.pfx not a *.cer file because I need a private key access (cer file loads Ok). I made pfx on my dev mochine like that:
makecert -r -n "CN=myhost.com, [email protected]" -sky exchange -b 01/01/2009
-pe -sv myhost.pvk myhost.cer
<b>pvk2pfx</b> -pvk myhost.pvk -spc myhost.cer -pfx myhost.pfx -po pass</code>
I am using version v5.131.3790.0 of makecert
Answer
Use the local computer store for the private key:
X509Certificate2 cert = new X509Certificate2("myhost.pfx", "pass",
X509KeyStorageFlags.MachineKeySet);
MachineKeySet is described as "private keys are stored in the local computer store rather than the current user store". The default with no flags is to place in the user store.
Even though you are reading the certificate from disk and storing it in an object the private keys are still stored in the Microsoft Cryptographic API Cryptographic Service Provider key database. On the hosting server the ASP.NET process does not have permission to access the user store.
Another approach (as per some comments below) is to modify the IIS Configuration or App Pool identity -- which do work. However, this assumes that there is access to these configuration items which may not be the case (e.g. in a shared hosting environment).