Certificate revocation checked failed
Recently I came across a CAS server that was rebuilt. Think of it as a new server you are introducing in your environment.
Everything looked good except certificate that we imported. The certificate looked good when looking at validity, issuing authority certificate and other dependencies. However, Exchange Management Console complained:
“The certificate status could not be determined because the revocation checked failed.”
Since the error seemed clear enough, we checked and verified that we can reach CRL. We could successfully access it and download CRL. We also ensured that there was no proxy servers configured or required, which they weren’t.
However, the server had its own mind.
KB979694 wasn’t applicable since there was no proxy in the environment.
The only logical thinking here was, why is “Local System” account (which the service uses to get the revocation status) unable to get to CRL. To get to the answer, we needed to check proxy settings of Local System account. How do you do that? You can’t simply start IE as different user!
That exactly is the purpose of this post. I found bits and pieces of information that helped me resolve the issue but not a one step document. In this post, I am trying to put it all together so you have one stop solution.
Here’s how you can fix the issue:
- Open up command prompt as Administrator
- Run “sc create testsvc binpath= "cmd /K start" type= own type= interact”
- This creates testsvc service which will run as local system and allow interaction with desktop
- The error “[SC] StartService failed 1053” is expected and can be ignored safely
- "c:\Program Files (x86)\Internet Explorer\iexplore.exe"
- In our case, either server build process or a setting from or a GPO was populating incorrect proxy settings.
You are now back to your desktop and we have corrected Internet Explorer settings for Local System (removing proxy configuration that was incorrect). After this, we restarted Exchange Management Console and verified certificate on CAS server in question. Certificate was no longer issuing the warning and we proceeded with assigning the certificate to appropriate services.
It is important to note that refresh time varies from immediate to more than few minutes so don’t fret over certificate still showing the same error. If, however, it takes more than 15 minutes, I would check if all steps were followed as mentioned above and configuration is correct for your environment.
Yet another issue put to bed. On to another.
Originally posted at http://blogs.technet.com/bshukla