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.
Thx for this article, i solved my Problem in a few minutes.
MS Support was not able so solve this Problem.
We ended up disabling the CRL check on the mailbox servers. I documented the process at the bottom of this thread:
https://social.technet.microsoft.com/Forums/exchange/en-US/1a89fff4-da6e-4055-be04-2e52af3ee76e/disable-crl-check-for-exchange-servers-without-internet-access?forum=exchange2010
Does anyone have any pointers, we are getting the error message (and have since inception of exchange 2010)
Assigning a direct internet route out to bypass the proxy server still doesn’t resolve the issue) or the steps above.
Funny enough however we do not experience any issues with any clients / CAS activity whatsoever.
Any pointers to get rid of this error would be appreciated as it’s irritating and prompts other departments to blame the certificate revocation error on other issues that are experienced.
Hi ,
Trust all is well at your end.
I have imported the new SSL certificate. And same issue that “certificate status could not be determined because the revocation check failed.”
I have already another old certificate in place and is working fine. ie proxy by pass all is et. But still revocation check failed status.
Question is , Can we enable and assign the services to this new SSL certificate and leave the status as it is.?
Is there there any issue doing it this way.?
thanks.
Z RATHER
Paul Cunningham,
THANK YOU, THANK YOU, THANK YOU, THANK YOU, THANK YOU
& THANK YOU
Excellent explanation, this perfectly solved my problem. I was using proxy settings in Internet Explorer and was getting revocation check failure.
Following this post and reopening my EMC after change fixed problem in first attempt.
Thanks a lot
Thanks for the article Paul fixed the issue.
Hi Paul,
This is really nice tutorial.but i have a query same problem i am facing on exchange server 2013. how to resolve this issue on exchange server 2013
The Real Person!
The Real Person!
Have you tried the same solution in the article above?
Awesome. We switched firewalls in a POC (that went south), when re-engaging the old FW, the EMC and EMS did not work? Spent HOURS trying to resolve PowerShell remote mng via IIS, BPA’s, EMTshooter, removing reg keys (HKEY_CURRENT_USERSoftwareMicrosoftExchangeServerv14AdminToolsodeStructureSettings), re-running winrm quickConfig, re-running PowerShell cmdlets (Set-PSSessionConfiguration Microsoft.PowerShell(32) -ShowSecurityDescriptorUI -force), checking windows cache (rundll32.exe keymgr.dll, KRShowKeyMgr), validating credential sets ($UserCredential = Get-Credential
(Enter domainnameuser & password)
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://adminsrv01.nhsadmin.local/PowerShell/ -Authentication Kerberos -Credential $UserCredential
Import-PSSession $Session
Get-ManagementRoleAssignment
Get-ExCommand)
As we believed that the WinHTTP had been ‘unaltered’ & nor had any of the old FW configs been touched?
Turned out (after seeing this article), we just had to do the following
From CMD
inetcpl.cpl (verify all’s well)
netsh winhttp reset proxy
netsh winhttp import proxy source=ie
All of 1 minute AARRRGGGGGHHHH.
Hi
I`m also having a problem. I have enabled the CAS server to have a direct route out with no proxy access and its still showing as certificate revocation failed đ
Hi Paul,
I am facing same issue. But there is no proxy in my environment. Also am using internal ca certificate which is deployed by us.
Regards,
Mahesh
Pingback: Exchange management Powershell Error Message: The WSMan client cannot process the request. Proxy is not supported under HTTP transport. | Rajisubramanian's Blog
It works like a charm đ
Thanks.
Fantastic Help – Exchange just collapsed when I changed the winhttp settings, the local exceptions saved it. Thanks again.
Pingback: Butsch.ch
Hi Paul,
Is there anyway to configure the CAS server to check CRL offline? Or doesn’t check CRL ???
In addition, what you said is that the server connect to CRL check link and firewall must allow that, but from what i captured on CAS server using WireShark, i can’t see any packet of HTTP request to the CRL check link?
Is there something that i misunderstand here??
Thanks for your support Paul !
The Real Person!
The Real Person!
There could be other causes of the error I suppose, but the common one tends to be CRL check failing due to firewall or other lack of outbound access.
i managed to get my live server working that sits behind a proxy, but still cannot get the other exchange box working which hasnt got a proxy server, goes direct.
managed to assign services via script…
Thanks for your help Paul, i have opened the firewall policy to connect CRL link and everything has worked!
But i still want to know how can we set config the registry in CAS server to check CRL offline that we imported manually !!
BRs
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?
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.
Pingback: Anonymous
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
Pingback: Exchange Server 2010 SSL Certificates
Pingback: Exchange 2010 and “The certificate status could not be determined because the revocation check failed” | DXPetti.com
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.
Hi Paul,
In my lab,I am not having any proxy server đ still getting this error.
Thanks.
Using the above has broken my connection and I cant get it back. EMC wont connect. STUCK
The Real Person!
The Real Person!
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.
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?
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.
Excellent !!!! no where i could find this info. thankssss
Thanks for the info, this helped me alot!!
Thanks as well.. fixed my issues too!
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 !
Huge Thanks! Solved my issue.
Neil
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 …
The Real Person!
The Real Person!
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.
Great article, thanks……
This solved the issue with my Exchange 2010 test box. The article was a huge help.
The Real Person!
The Real Person!
Glad you found it useful Jason, thanks for taking the time to leave a comment.
Thank you very much !!!!