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.

Exchange 2010 Certificate Revocation Checks and Proxy Settings

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.

Exchange 2010 Certificate Revocation Checks and Proxy Settings

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.

Exchange 2010 Certificate Revocation Checks and Proxy 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.

Exchange 2010 Certificate Revocation Checks and Proxy Settings

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 the Author

Paul Cunningham

Paul is a former Microsoft MVP for Office Apps and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul no longer writes for Practical365.com.

Comments

  1. Reischl

    Thx for this article, i solved my Problem in a few minutes.
    MS Support was not able so solve this Problem.

  2. Rob

    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.

  3. Z RATHER

    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

  4. Turki Alibrahim

    Paul Cunningham,
    THANK YOU, THANK YOU, THANK YOU, THANK YOU, THANK YOU
    & THANK YOU

  5. Wajeeh

    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

  6. Paul

    Thanks for the article Paul fixed the issue.

  7. anirban

    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

  8. Ian Stockdale

    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.

  9. Rob Betts

    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 🙁

  10. Mahesh Khanolkar

    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

  11. Amir

    It works like a charm 🙂
    Thanks.

  12. Dan Evans

    Fantastic Help – Exchange just collapsed when I changed the winhttp settings, the local exceptions saved it. Thanks again.

  13. Pham Trung Duc

    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 !

      1. gary

        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…

      2. Pham Trung Duc

        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

  14. gary

    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?

  15. Reid

    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.

  16. Carlos

    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

  17. Wasim Shaikh

    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.

  18. Wasim Shaikh

    Hi Paul,

    In my lab,I am not having any proxy server 🙁 still getting this error.
    Thanks.

  19. Imi

    Using the above has broken my connection and I cant get it back. EMC wont connect. STUCK

    1. Avatar photo

      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.

  20. Andrew

    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?

  21. Matt

    At what point does the CRL URL get checked? Can it be manually initiated?

    1. Matt

      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.

  22. Zannuzi

    Excellent !!!! no where i could find this info. thankssss

  23. Steve

    Thanks for the info, this helped me alot!!

  24. Tobias

    Thanks as well.. fixed my issues too!

  25. Chantal

    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 !

  26. Neil

    Huge Thanks! Solved my issue.

    Neil

  27. Chantal

    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 …

    1. Avatar photo

      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.

      1. Chantal

        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.

  28. Dinesh Silva

    Great article, thanks……

  29. Jason Bjornsen

    This solved the issue with my Exchange 2010 test box. The article was a huge help.

    1. Edmar

      Thank you very much !!!!

Leave a Reply