In this article I am covering all the possible scenarios and resolution for a very common error that you may receive when Application Pool Service account is changed or Certificate is renewed and imported in the CRM/ADFS  Server environment.

Also, covering details on Private Key folder concept, other issues and troubleshooting related to certificate and WSE X.509 Certificate tool.

 

Error Details:

 

While accessing CRM/ADFS federated url , you are getting"Keyset does not exist</"

https://internalcrm.habib.local:5555/FederationMetadata/2007-06/FederationMetadata.xml

https://auth.habib.local:5555/FederationMetadata/2007-06/FederationMetadata.xml

https://sts.habib.local:444/FederationMetadata/2007-06/FederationMetadata.xml

 

 

 

Expected result:

 

 

Concept:

When you access the federated url, CRM Application pool or ADFS Application pool tries to access the Private Key of the certificate, which is stored locally in the Web server in below location in CRM/ADFS Server

%ALLUSERSPROFILE%\Microsoft\Crypto\RSA\MachineKeys

OR

C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys

 

If the private key is missing or there is some permission issue to access MachineKey folder, it throws "Keyset does not exist" error.

The private key is stored in below location in the format of Key_GUID (screenshot below)

 

Since the service account tries to access Keys, we have to make sure we have given appropriate rights to service account to MachineKeys folder. Also, the right Private Key exists in the MachineKey folder.

 

 

Troubleshooting

 

Scenario -1

  • Issue after deploying a new CRM Claims/IFD environment.

OR

  • You have Claims and IFD configured in CRM. Everything was working fine. However, as soon as you have changed the CRM/ADFS application pool service account to some other account the claims or IFD authentication have stopped working. While investigating more you found that the claims or IFD federated url is no more accessible. You are getting "Keyset does not exist" error in the error message.

 

Troubleshooting Steps:

  1. First check the service account which is running CRM App pool or ADFS App pool
  2. Now open certificate manager, in personal store, locate your certificate. Right click on the certificate and select "Managed Private Keys" option
  3. In the permission window, check if your app pool service account is given appropriate permission (Read permission should be fine, otherwise you can give Full control)

    In below screenshot I have given full permission on my wildcard certificate *.habib.local to my CRM App Pool account – "habib\CRMAppPoolSvc"

     

     4. Once the permission is given, perform an IISRESET and try accessing the CRM federated url 

https://internalcrm.habib.local:5555/FederationMetadata/2007-06/FederationMetadata.xml

https://auth.habib.local:5555/FederationMetadata/2007-06/FederationMetadata.xml

 

 

Scenario-2

  • Your CRM/ADFS certificate was expired recently. You have renewed the certificate and imported it. However, while accessing the Claims/IFD federated url or accessing STS url, you are getting "Keyset does not exist" error in the error message.

 

Troubleshooting steps:

When we import any certificate, the overall process tries to access location "%ALLUSERSPROFILE%\Microsoft\Crypto\RSA\MachineKeys " and try to copy the public key file. Now while are performing this certificate import task, there are chances that your currently logged in account is not having sufficient permission to access MachineKeys folder. Due to this you won't see any new public key file getting added to MachineKey folder. In order to isolate/troubleshoot this issue, you can perform below steps:

  1. Let's say you are logged into CRM/ADFS server as user – habib\crmadmin

    Navigate to folder, "%ALLUSERSPROFILE%\Microsoft\Crypto\RSA\MachineKeys " and  check the security permission and make sure you have given full control to the logged in account on the MachineKey folder.

  2. Now try to import the certificate again and you should see a new public key file getting added to the MachineKey folder
  3. In case, due to group policy or some other issues, if it fails to copy the key file, you may try giving permission to "Everyone"  group and try importing certificate again.
  4. Once the certificate public key is copied, perform an IISRESET and try to access the federated url again

 

Other causes and troubleshooting:

 

If you have already tried all the troubleshooting steps mentioned in this article, then there are chances that either:

  1. Service account have issues due to group policies. Trying all the steps with any service account would help to isolate the issue.
  2. Could be the certificate is not exported properly with private key. Re-exporting the certificate properly may help.
  3. Some other unknown issue. In that case you can try using process monitor to analyze overall process failure

 

 

Additional information:

If the MachineKey folder have multiple keys and you would like to verify quickly if the new key file is imported or accessible, you can use Microsoft's WSE X.509 Certificate tool.

Download Link:

http://www.microsoft.com/en-in/download/details.aspx?id=14089

 

How to use Certificate Tool: http://msdn.microsoft.com/en-us/library/aa529278.aspx

 

  1. Access the WSE X.509 Certificate tool using the App Pool service account
  2. Select Certificate location- Local computer, Store name- Personal
  3. Click Open certificate and then select your newly imported certificate
  4. Now click "view private key properties", this should show the private key file, accessed from MachineKey folder

 

        5. If there are some permission issues, then you should get error "Private key does not exist or is not accessible"