After importing a new Certificate for the SecureAuth IdP, Users are unable to login.
The Warning.log shows
"Encryption.DecryptRSAUTF8 exception: Invalid provider type specified."
The permissions on the MachineKeys folder have been modified to non-standard and this causes the Certificate Provider type to be Microsoft Software Key Storage Provider instead of Microsoft RSA SChannel Cryptographic Provider
A way to check this is to :
1. On the IdP open an Admin cmd prompt
2. Type in certutil -store my > c:\temp\certinfo.txt
3. This dumps out info about all the certs in the Local Computer "personal" store into a txt file called certinfo.txt in c:\temp (Make sure C:\temp exists)
4. Open c:\temp\certinfo.txt and find the certificate that is in use by searching for the certificate name - it should appear as Subject: CN=YourIDP.example.com, etc
5. Look for the Provider = " " section of that certificate - If it is Microsoft Software Key Storage Provider then the MachineKey permissions are most likely the cause
Disclaimer: These instructions explain how to reset permissions back to the standard Windows permissions. SecureAuth recommend you back up your machine before making any changes. SecureAuth are not responsible for issues caused by incorrect modification of permissions.
1. Take a backup/snapshot of the IdP
2. Open C:\ProgramData\Microsoft\Crypto\RSA
3. Right click on MachineKeys and select properties
4. Click Security | Advanced
5. If Inheritance is Enabled, Disable it and select the option to copy the permissions
6. Click Everyone and click Edit
7. Set "Applies To:" to "This folder only"
8. Click Show advanced permissions. Match the permissions to this screenshot
9. Click OK - Don't worry if you get an access denied setting some of the permissions
10. Re-Import the Certificate
11. The Users should now be able to use the IdP correctly.
SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.
Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.