Explanation of CRLs, OCSP and Revoked Certificates
Normally only client computers need to check if a certificate has been revoked by a certificate authority so they can warn users about trusting a website or email server or device they connect to. In Microsoft Exchange 2010 was designed to check this for administrators, so they wouldn't be inadvertently configuring Exchange to use a revoked SSL Certificates to send to clients when checking their email. To test your current proxy settings (this is most useful for troubleshooting the Exchange 2010 error: The certificate status could not be determined because the revocation check failed.
This is a really good idea, but they unfortunately don't allow you to assign an SSL certificate in the Exchange Management Console without it passing with flying colors that it hasn't been revoked by the certification authority (CA) that issued it. This causes problems if a certificate is valid (not on a revoked list of certificates) but the server can't make a connection with a CA to see if that certificate was revoked, and based on the error above it sounds more like a certificate has been revoked, than the server just wasn't able to connect to see if it was revoked which is more often than not the case.
When we have run into this issue in the past, it has been caused by WinHTTP proxy settings or firewall settings not allowing the Exchange server to perform revocation checks. The DigiCert Certificate Management Utility allows you to check if your server can reach the OCSP or CRL successfully using the WinHTTP proxy settings used by exchange, so that a certificate can pass this check.
With SSL Certificates, certificate authorities keep track of all certificates that have been revoked and create a list of the serial numbers of the revoked certificates and place these in a certificate revocation list. Then clients will connect to the URLs and download a certificate's CRL and will search for the serial number of an SSL certificate they receive from a server to make sure it's not revoked. The URLs for a certificate's CRL(s) can be found by running the DigiCert Utility, double-clicking your certificate, going to the details tab and scrolling down to and selecting the item 'CRL Distribution Points'.
The process of having to download a certificate authority's entire CRL file and check it for revoked certificates has been somewhat deprecated by the creation of the Online Certificate Status Protocol (OCSP). OCSP is like a CRL but simpler and faster for clients and servers. OCSP amounts to a client's browser looking at a serial number, then querying the CA over OCSP whether a particular SSL Certificate has been placed on their CRL or not.
To use the DigiCert Certificate Utility to determine if your server is having trouble accessing the certificate revocation list URLs for an SSL Certificate or the OCSP service, click the DigiCert Icon in the Upper-Left corner of the program, and choose Diagnostic Assistance.
Diagnostic Assistance Screen
Click Test DigiCert CRL Access, then click Perform Test.
If the utility is able to reach the DigiCert's CRLs you'll receive a message showing you that it successfully reached the CRLs.
Click Test DigiCert OCSP Access, then click Perform Test.
If the utility is able to reach DigiCert's OCSP you'll receive a message showing you that it worked.
Microsoft computers and servers use separate settings for both 32 bit and 64 bit WinHTTP Settings, so if you're using a 64 bit server you should test both of these.
After opening the Diagnostic Assistance screen under the Server Proxy Settings, you'll see your WinHTTP settings displayed:
Access Type: Will list direct access if no proxy is configured or will list any configured proxy server(s)
Proxy Servers: Lists the above settings.
Bypass List: Shows the list of domains that are configured to not use the proxy (e.g. your active directory