The Microsoft Exchange Team blog posted about an issue people are experiencing in the field in which certificate revocation status check failures prevent you from assigning a certificate to any Exchange services.
If Exchange can’t access the CRL, the certificate status is returned as RevocationCheckFailure by the shell. In EMC this is displayed as The certificate status could not be determined because the revocation check failed.
When a certificate fails a revocation check due to any of the above reasons, the EMC prevents you from assigning the certificate to any Exchange service. Note, this does not impact certificates that have already been assigned to Exchange services. The services will continue to function.
- Source
Two of the causes of this are listed as:
# Network or proxy misconfiguration, or a firewall rule preventing Internet access
# Intentional blocking of Internet connectivity from the server
In a comment on the post I mention using proxy settings to work around the issue. In other words, if you can use a proxy in Internet Explorer to browse the web when you’re logged onto the server, then you can use this workaround. However, you need to proceed with caution or you may inadvertently break your management connection to the Exchange server.
Firstly, you can check the server’s proxy settings using the netsh command (proxycfg is no longer available in Windows Server 2008 R2).
C:\>netsh winhttp show proxy
Current WinHTTP proxy settings:
Direct access (no proxy server).
Note: if you can resolve the direct access issue at your proxy/firewall then that is going to be easier than using this procedure. Otherwise, read on.
If you have the correct proxy settings configure in Internet Explorer then netsh lets you import that configuration to the server.
C:\>netsh winhttp import proxy ie
Current WinHTTP proxy settings:
Proxy Server(s) : 10.10.10.10:80
Bypass List : (none)
Depending on your environment you may find that this breaks you connection to the Exchange server using either the Exchange Management Console or Exchange Management Shell.
VERBOSE: Connecting to ex1.exchangeserverpro.local
[ex1.exchangeserverpro.local] Connecting to remote server failed with the following error message : The client cannot c
onnect to the destination specified in the request. Verify that the service on the destination is running and is accept
ing requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonl
y IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and co
nfigure the WinRM service: "winrm quickconfig". For more information, see the about_Remote_Troubleshooting Help topic.
+ CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [], PSRemotingTransportExc
eption
+ FullyQualifiedErrorId : PSSessionOpenFailed
The reason for this is that the Exchange Management Shell is trying to make a remote connection to the server, even when you are logged on to the server that you want to manage. This is known as Remote Shell and you can read more about it here.
You can see here that when I launch the Exchange Management Shell on my lab server there are corresponding entries in the IIS log files for the connection that I just made to the /powershell virtual directory.
The reason that this breaks your management connectivity to the server is that the proxy you are using is not correctly configured to let you access local websites. Fortunately you can resolve this by using proxy exceptions on your local Internet Explorer settings.
If I configure Internet Explorer to automatically bypass for local sites, and then re-import the settings to the server with netsh, I see different output.
C:\>netsh winhttp import proxy ie
Current WinHTTP proxy settings:
Proxy Server(s) : 10.10.10.10:80
Bypass List : < local >
In some cases this still might not work if Internet Explorer is not correctly detecting local sites and bypassing the configured proxy. In that case you can manually specify the proxy exceptions in Internet Explorer.
Again when you re-import using netsh you see a different result.
C:\>netsh winhttp import proxy ie
Current WinHTTP proxy settings:
Proxy Server(s) : 10.10.10.10:80
Bypass List : *.exchangeserverpro.local;< local >
Alternatively, you can set a proxy configuration for the server that is different to that of your own Internet Explorer settings.
C:\>netsh winhttp set proxy proxy-server="http://10.10.10.10:80" bypass-list="*.exchangeserverpro.local"
Current WinHTTP proxy settings:
Proxy Server(s) : 10.10.10.10:80
Bypass List : *.exchangeserverpro.local
Again you need to make sure you set the correct exceptions so that management connectivity to the server isn’t broken in the process.
If you can get the proxy settings configured with the right proxy and exceptions you should be able to connect to the server with the console and shell, and also have the server successfully perform CRL checks for your SSL certificates.
About Paul Cunningham
This solved the issue with my Exchange 2010 test box. The article was a huge help.
Glad you found it useful Jason, thanks for taking the time to leave a comment.
Great article, thanks……
Hello all,
Yes, I got the proxy settings right and can acces EMC and PowerShell correctly, but still my cert still says revocation check failed …
Chantal, check your firewall/proxy logs to see whether it is being blocked for some other reason.
You can also try using the Exchange Management Shell instead to enable the certificate for services, because the shell doesn’t worry about the CRL check.
Thanks for your response.
I did use the shell to enable my cert, and yes, it does use the CRL check too.
I have an open call with MS and they tell me they have had a whole bunch of calls with the same prob in the pass few weeks.
Hope they find a solution soon … What they suggested for now is to ask our cert supplier to generate a new cert and to reinstall the new one.
We’ll see.
Huge Thanks! Solved my issue.
Neil
Finally, we found that our proxy server was preventing the Exchange servers to access the required crl check
URLs.
So we had to create a isa access rule to allow all exch servers to access the URLs and now, it works fine !
Thanks as well.. fixed my issues too!
Thanks for the info, this helped me alot!!
Excellent !!!! no where i could find this info. thankssss
At what point does the CRL URL get checked? Can it be manually initiated?
Sorted…
I found in our case we needed to use an IP address vs a hostname, had to state the port as it was not a standard one, had to include a bypass for the domain the server was in,
netsh winhttp set proxy proxy-server=”http=192.168.0.1:8090;https=192.168.0.1:8090″ bypass-list=”*.mydomain.co.nz”
…after that we “refreshed” and CRL error disappeared and the certificate red x changed to a tick inidcating no issues.
We also had an invalid CRL URL in the Thawte certificate but thats another story we managed to sort with a host file entry pointing at the IP address of the correct server.
What if you are using a proxy.pac on IE for proxy settings, how do u proceed in the shell because i also have the revocation check failure issue?
Using the above has broken my connection and I cant get it back. EMC wont connect. STUCK
As the article suggests, using this tip can break your Exchange tools connection to the server. The solution is explained in the post – use a bypass in your IE settings or when running the netsh command.
Hi Paul,
In my lab,I am not having any proxy server
still getting this error.
Thanks.
Done!, was using a stand-alone CA and CAS was not having CRL installed locally for the Root CA, downloaded CRL from the URL and it worked.
In my case.. EMC was unable to access the CA crl’s Distribution Point.. What I did was to allow Anonymous over the http://CA_servername/CertEnroll/ virtual directory. After EMC refresh.. certificate was valid for using it.
REGARDS
Our Mailbox servers have no Internet access. We are seeing requests every few seconds from these servers to crl.microsoft.com. These requests are being blocked and reported by our firewall.
Your article mentions setting up a proxy to allow access to the CRL servers, but do you know of a way to turn off requesting CRLs all together?
Thanks.
OK, i have followed the instructions as per the godaddy ssl cert procedures. All fine, apart from getting the ‘revocation check failed’ error. Found the server using a proxy. SO uncheck this.
Now how do i force the server to check again?