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.