This is a customer problem I ran into recently. They wanted to change the SMTP server configuration for CLM and did this by running the CLM Configuration Wizard. By default the Wizard will issue new certificates to the Agent accounts. Now, CLM uses the Hash, or Thumbprint of these certificates to encrypt certain data in the database, so if you issue a new certificate ….. CLM can no longer decrypt the data.
If you’ve only done one iteration of the certificate renewal, then with the right hotfix package and configuration, we can recover from this problem. If you’ve done more than one iteration, life gets a bit more complicated.
Without repeating all the steps we went through to get to a solution, here’s the email I sent summarizing what problems we encountered and what we can do about them:
After running the CLM configuration wizard and letting it create new certificates for the CLM Agent accounts, you had 2 problems.
1. “ASN1 bad tag value met” following these steps.
· User enrolled in a smartcard profile template
· Verified that the smartcard login works
· Ran the config wizard and generated new CLM Agent certs.
· Logged in as Admin and retired the card.
2. After running the CLM wizard and updating the clmAgent certificate, we tried to retire a smartcard that had been issued with the old certificate we get the error “The card cannot be accessed because the wrong PIN was presented”
#1 Was fixed in a patch we provided in conjunction with the Clm.Decryption.Certificate.Hash setting in the web.config. Refer to http://support.microsoft.com/kb/960765 for details.
#2 We found two solutions here
1. Ran the certificate mmc as the clmAgent user.
2. Right-clicked on the expired certificate and selected “Request new certificate using same key”.
3. Backed up the web.config file, then put the thumbprint from the new certificate in the 3 locations (note: the thumbprint is not the same as the certificate I renewed from).
The 3 locations are
4. IIS reset.
B. In the Initialization Data of a profile template, enter the thumbprint of the clmAgent cert. that was current when the card was issued.
The solution to #1 will work as long as the agent cert was only replaced one time prior to applying the patch. The patch will prevent problems with Agent cert renewals in the future.
Solution #2B will work if all cards were issued with the same clmAgent cert (basically the same as #1).
If not, I don’t think we have any elegant solutions.
1. You will need to update the thumbprint in the Clm.Decryption.Certificate.Hash to that of the the clmAgent cert that was current when the card was issued.
2. Update the profile template to have the thumbprint in the Initialization Data to that of the clmAgent cert that was current when the card you’re accessing at the moment was issued.
Moving forward, when renewing cards I suggest this. Create a new profile template with the current thumbprint, then retire the cards and reissue them with the new profile template. This will avoid problems with accessing these cards in the future.
It is important to note that all the solutions above assume that the Agent cert whose thumbprint(s) we are using has not been deleted from the Agent’s certificate store.
So what did we learn from this ?
Be really, really careful if and when you run the Configuration Wizard. The best practice is really to not let the Wizard either create the CLM Agent accounts or issue certificates to those accounts.
More on that in another future blog on best practices for the Configuration Wizard.