CRL revocation check fails due to a proxy setting having been applied to the Local System account.
In certain situations an errant Active Directory GPO can set the Local System account to use a proxy setting which is invalid. Once this happens the Windows CAPI2 API used by SecureAuth to verify a CRL will fail as the request is generated by IIS and executes under the IIS security privileges, IIS is set by default to use the Local System account context.
To verify that CAPI2 is communicating through a proxy enable CAPI logging in the Windows Event Viewer. If the proxy server is incorrect, an action "BadProxy" is logged in the "CryptRetrieveObjectByUrlWire" event data. This is followed by the system error message explaining the error. For example, if DNS reports an error because the DNS name of the proxy server cannot be resolved, an action "Call_WinHttpSendRequest" with error code "2EE7," which is the hexadecimal value for error constant "ERROR_WINHTTP_NAME_NOT_RESOLVED," is logged. If the connection to the proxy server cannot be established, an action "Call_WinHttpSendRequest" with error code "2EFD," which is the hexadecimal value for error constant "ERROR_WINHTTP_CANNOT_CONNECT," is logged.
There are three ways you can disable the Proxy setting for the Local System account:
Issue the following command using the bitsadmin tool: bitsadmin /util /setieproxy localsystem NO_PROXY
Replace the following registry key with a default key from the applicable Windows Server version: HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\DefaultConnectionSettings
Use the netsh command "netsh winhttp reset proxy" to remove the proxy or netsh winhttp set proxy proxyservername:portnumber to configure a valid proxy.