After deployment to IIS server got this error:
An unhandled exception occurred while processing the request.
CryptographicException: OpenCSP failed with error code 2148073494.
System.Security.Cryptography.CryptographicException: OpenCSP failed with error code 2148073494.
at Internal.NativeCrypto.CapiHelper.CreateProvHandle(CspParameters parameters, Boolean randomKeyContainer)
at System.Security.Cryptography.RSACryptoServiceProvider.get_SafeProvHandle()
at System.Security.Cryptography.RSACryptoServiceProvider.get_SafeKeyHandle()
at System.Security.Cryptography.RSACryptoServiceProvider..ctor(Int32 keySize, CspParameters parameters, Boolean useDefaultKeySize)
at System.Security.Cryptography.RSACryptoServiceProvider..ctor(CspParameters parameters)
at Internal.Cryptography.Pal.CertificatePal.<>c.
at Internal.Cryptography.Pal.CertificatePal.GetPrivateKeyT
at Internal.Cryptography.Pal.CertificatePal.GetRSAPrivateKey()
at Internal.Cryptography.Pal.CertificateExtensionsCommon.GetPrivateKeyT
seems this is this: https://github.com/dotnet/corefx/issues/2583
So is this an IdentityServer issue, or can we close?
FYI how we fixed it.
It seems, if the imported certificate has a private key AND is marked as exportable, Windows is requiring some additional security,
Once we imported the PFX with the private key and did NOT mark the private key as exportable, the error went away.
We've encountered this issue as well. We're using dotnet core. We abandoned X509 certs in favor of RSA keys.
http://stackoverflow.com/questions/42102401/opencsp-failed-with-error-code-2148073494
I can also affirm that setting AddSigningCredential works only with RSA keys on IIS.
The trick with marking private key not as exportable didn't work.
Setup is: IIS 10, web app on DotNet Core 1.1, IdentityServer4
It appeared that I've forgotten to grant the app pool read access to the PK.
So the exception is gone. It's worth for others also to check that permission.
Vielen Dank, Dominick
@apacherose Did you change the Identity of your app pool from ApplicationPoolIdentity to something else? Maybe NetworkService? Or did you just end up giving Everyone access to the cert?
No, app pool runs under ApplicationPoolIdentityand I just gave read permission for IIS AppPool/YourPoolName to the private key. I did this through the mmc console.
I just had this error hosting in IIS using a self signed certificat. I run the ApplicationPool with ApplicationPoolIdentity. Giving IIS_IUSERS Read permission to the private keys in CertManager solved the issue.
Thanks @Robban1980. Here's some PowerShell to add a cert to the store and then set the ACL appropriately, leaning on this thread.
Note that it's IIS_IUSRS, at least on IIS 10. Note also that you will have to restart W3SVC (ie restart IIS entirely) for these changes to take effect. Note finally that you can run this as many times as you like, it's conveniently idempotent.
# assuming $pfxFile = PFX key pair, $securepwd = a secure string to unlock PFX file
# you could store both in S3, as a k8s secret, or anywhere really
$cert = Import-PfxCertificate -FilePath $pfxFile Cert:\LocalMachine\My -Password $securepwd
Write-Output "Imported { Thumbprint = $($cert.Thumbprint), Subject = $($cert.Subject), Expires = $($cert.GetExpirationDateString()) }"
$rsaFile = $cert.PrivateKey.CspKeyContainerInfo.UniqueKeyContainerName
$keyPath = "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\"
$fullPath = Join-Path $keyPath $rsaFile
$acl = Get-Acl -Path $fullPath
$permission = "IIS_IUSRS", "Read", "Allow"
$accessRule = New-Object System.Security.AccessControl.FileSystemAccessRule $permission
$acl.AddAccessRule($accessRule)
try {
Set-Acl $fullPath $acl
Write-Output "ACL set on private key to include IIS_IUSRS"
}
catch {
Write-Output "Error: unable to set ACL on private key"
exit 1
}
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Most helpful comment
I just had this error hosting in IIS using a self signed certificat. I run the ApplicationPool with ApplicationPoolIdentity. Giving IIS_IUSERS Read permission to the private keys in CertManager solved the issue.