Troubleshooting: "Invalid Provider Type Specified" Login Failure

Version Affected: All
 
 

Overview

This article explains how to resolve a login failure where the Warning or Error log shows "Encryption.DecryptRSAUTF8 exception: Invalid provider type specified" or "SAML20SPInit exception error: Invalid provider type specified." In both cases, the signing certificate's Cryptographic Service Provider (CSP) has been set to Microsoft Software Key Storage Provider instead of the correct RSA/AES-based provider.

• See Cause 1 - If this started after modifying folder or security permissions (not after a backup/restore), the cause is most likely the MachineKeys folder permissions.
• See Cause 2 - If this started after a backup and restore onto a new IdP, the cause is most likely the certificate being imported with the wrong provider during the restore.

These causes are not related, so a fix for one cause will not resolve the other cause.

 

In this article

• Cause 1: MachineKeys Folder Permissions Changed
• Cause 2: Certificate Imported with the Wrong Provider During Backup/Restore

Cause 1: MachineKeys Folder Permissions Changed

The permissions on C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys have been changed from the Windows standard, which causes the signing certificate's provider to be set to Microsoft Software Key Storage Provider instead of Microsoft Enhanced RSA and AES Cryptographic Provider (on 9.2 and later; Microsoft RSA SChannel Cryptographic Provider on earlier versions).

To check which provider is currently in use:

1. Open an Admin command prompt on the IdP.
2. Run (confirm C:\temp exists first):
   

   certutil -store my > c:\temp\certinfo.txt

3. Open c:\temp\certinfo.txt and find the certificate in use by its Subject, for example CN=YourIDP.example.com.
4. Check that certificate's Provider = value. If it is Microsoft Software Key Storage Provider, the MachineKeys permissions are most likely the cause.

Resolution 1:

Disclaimer: these steps reset permissions back to the Windows standard. Back up the machine before making any changes — SecureAuth is not responsible for issues caused by an incorrect permissions change.

To resolve this:

1. Take a backup or snapshot of the IdP.
2. Open C:\ProgramData\Microsoft\Crypto\RSA.
3. Right-click MachineKeys and select Properties.
4. Click Security > Advanced.
5. If Inheritance is enabled, disable it and choose to copy the existing permissions.
6. Compare the current permissions to the standard set below — any extra account can cause this issue. The standard permissions list only Everyone and Administrators.
   
7. Click Everyone, then click Edit.
8. Set Applies to to This folder only.
9. Click Show advanced permissions, and match the permissions to the checked boxes below: List folder / read data, Read attributes, Read extended attributes, Create files / write data, Create folders / append data, Write attributes, Write extended attributes, and Read permissions. Leave Full control, Traverse folder / execute file, Delete subfolders and files, Delete, Change permissions, and Take ownership unchecked.
   
10. Click OK. It is fine if some permissions show Access Denied.
11. Re-import the certificate.
12. Confirm users can now log in to the IdP.

Cause 2: Certificate Imported with the Wrong Provider During Backup/Restore

During a backup and restore onto a new IdP, the signing certificate can be imported with the wrong CSP.

Resolution 2:

First rule out Cause 1 (MachineKeys permissions) using the steps above — if that resolves the issue, the steps below aren't needed. To resolve Cause 2:

1. From an Admin command prompt or PowerShell, run:
   

   certutil -store my > c:\temp\certinfo.txt

2. Check the Provider = value for any SecureAuth G3 certificate. If it is set to Microsoft Software Key Storage Provider, it needs to be corrected — it should be Microsoft Enhanced RSA and AES Cryptographic Provider.
3. Export the certificate that has the wrong provider as a .pfx file.
4. Delete the certificate from the store after exporting it.
5. Re-import it with the correct provider:
   

   certutil -csp "Microsoft Enhanced RSA and AES Cryptographic Provider" -importPFX -p "<password>" "D:\Temp\<certificate_name>.pfx"

6. Run certutil -store my again and confirm the Provider is now correct.
7. Set permissions back on the certificate:
   • NETWORK SERVICE — Read only
   • IIS AppPool\SecureAuth0Pool — Read only

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.