It seems to be a FAQ disabling revocation checking in specific scenarios. This can be either a test or a formerly badly configured environment.
While it is not recommended to turn off revocation checking, I want to provide you some references where you can find technical information to alter the verification of a certificate revocation list (CRL).
It is important to understand, that CRL checking takes place on a per application basis. Therefore, Windows has no central switch that would turn on or off revocation checking for all software running on a computer.
Even if a revocation check is triggered by an application it is usually performed by the crypto layer in the Windows operating system because it makes not sense that every application implements its own CRL verification code.
On Windows Vista and newer versions of Windows, you can enable CAPI2 logging in the Eventlog so that application status messages about the success or failure of CRL checks are created. Some applications make verification failures visible to the user other applications stay silent and suppress such messages.
For detailed information how to control the CRL verification state see the following articles per product.
Changing the CRL verification behavior for Active Directory Federation Services 1.x, see the TechNet article Turn CRL checking on or off.
For Active Directory Federation Services 2.0 use the PowerShell cmdlet Set-ADFSRelyingPartyTrust with the parameter EncryptionCertificateRevocationCheck 'None'.
Certification Authority (CA)
To disable the CRL verification of the CA certificate while the CA service is starting, perform the following command:
certutil –setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE
The command is also explained in the Custom CA Configuration whitepaper.
The blog post Configuring Exchange Servers Without Internet Access provides information how to alter the CRL behavior for Exchange.
Forefront Identity Manager (FIM)
Forefront Identity Manager is leveraging the .NET framework and therefore, Microsoft Knowledgebase article FIX: A .NET Framework 2.0 managed application that has an Authenticode signature takes longer than usual to start may apply if the FIM server has no internet connectivity.
IPSec is configurable as core component since Windows 2000. In Windows Vista and newer Windows versions, IPSec can be alternatively configured through the Windows Firewall. Therefore, you have to determine the type of configuration that is applied.
The following registry keys must be configured to change the CRL verification behavior for the IPSec core functionality:
The default for Windows XP and Windows Server 2003 for IKE certificate based authentication is StrongCRLCheck=1 behavior. The registry key doesn't exist by default. The default behavior means Windows tries to get the CRL but allows any kind of failure to retrieve the CRL and fails only when the CRL has been retrieved and shows that the cert is actually revoked. For more information see paragraph “CRL checking” in the Microsoft TechNet article Public Key Certificate.
To alter the CRL checking for the Windows firewall integrated IPSec functionality, the following registry key must be changed:
The above key should be maintained with the netsh advfirewall set global ipsec strongcrlcheck command. For more information see the Microsoft TechNet article Netsh Commands for Windows Firewall with Advanced Security.
The registry and group policy configuration for CRL checking in Internet Explorer is explained in the TechNet article Internet Explorer URL Action and Advanced Security Settings in Group Policy.
Note: On Windows Vista and on, CRL checking for server certificates is turned on by default as described in HTTPS Security Improvements in Internet Explorer 7.
Internet Information Server (IIS)
For information about CRL checking in IIS see the TechNet article Checking the Status of Client Certificates in IIS 6.0.
The CRL verification behavior in Outlook is controlled with several configuration settings as described in the TechNet article Set consistent Outlook 2007 cryptography options for an organization.
Secure Socket Tunneling Protocol SSTP
The Microsoft Knowledgebase article Registry entries that Routing and Remote Access adds in Windows Server 2008 describes the NoCertRevocationCheck parameter which is used to control CRL checking with SSTP.
The CRL verification behavior for Smartcard logon is explained in the Microsoft Knowledgebase article You receive a "Logon failure" message when you use a smart card on a Windows Server 2003-based computer.
See also the Certificate revocation support paragraph in the Smart Card Authentication Changes document.
System Center Configuration Manager
For System Center Configuration manager see the TechNet article How to Enable or Disable Certificate Revocation Checking (CRL) on Clients.
Unified Access Gateway (UAG)
CRL checking for the reverse proxy functionality in UAG is described in the Microsoft TechNet article Forefront UAG registry keys. Look for the ValidateRwsCertCRL parameter.
For the DirectAccess functionality available in UAG, see the blog post UAG DirectAccess Step by Step Guide CRL Check Update.