There are a number of reasons that a web site could have a delay (hang) that could cause problems.  I am going to talk about a common one that we see which is the CRL.

What we have seen in the past is the Crypto API’s are trying to update the Certificate Revocation List (CRL) from the internet. If the server doesn’t have permission to access the internet you get the delay while we wait for the request to time out.

The server is trying to get the certificate revocation list from one of these:

http://crl.microsoft.com/pki/crl/products/CodeSignPCA.crl
http://crl.microsoft.com/pki/crl/products/CodeSignPCA2.crl

There are a few ways to resolve this.  The callstack will look like:

0x0611b6b4 0x77e41817 kernel32!WaitForSingleObjectEx+0xac 
0x0611b70c 0x77da1bbb advapi32!BaseSetLastNTError+0x14 
0x0611b724 0x73ca57c9 cryptnet!CryptRetrieveObjectByUrlWithTimeout+0x12d 
0x0611b750 0x73ca56c8 cryptnet!CryptRetrieveObjectByUrlW+0x99 
0x0611b77c 0x73ca3392 cryptnet!RetrieveObjectByUrlValidForSubject+0x37 

This is also talked about on other blogs here and here.

The ways to resolve it:

1. Unblock access to the above URL so CRLs can be retrieved when needed. This is the *PREFERRED* approach.

2. Turn off CRL checking by creating a turnoffCRL.reg file with this as the content:

Windows Registry Editor Version 5.00
[HKEY_USERS\S-1-5-20\Software\Microsoft\Windows\
CurrentVersion\WinTrust\Trust Providers\Software Publishing] "State"=dword:00023e00

Note that this would be considered to be compromising the integrity of the .Net signed packages stuff as we would have prevented any compromised certificates from being disabled automatically.

2. Manually update the CRL, by first downloading the file from the above URL, then running this command:

certutil -addstore CA CodeSignPCA.crl
certutil -addstore CA CodeSignPCA2.crl

Please note that this approach is NOT preferred. This is due to the fact that this would be a temporary relief -- only until this downloaded CRL expires. After it expires, the server would then make another attempt to retrieve current list, which would bring this whole problem back.

In one particular case, the CodeSignPCA.crl is set to expire on 1/4/2009 -- which would give us just under 2 months before the issue re-appears.

3. Reduce the timeout for the retrieval of the CRL to a small amount via the registry key.

UPDATE

4. Use the following workarounds:

geneartePublisherEvidence=false
<GeneratePublisherEvidence> Element

This is a good recommendation to just add this to the ASPNET.CONFIG file as this way you don’t turn off the CRL system wide. 

 

You can read more about Certificate Revocation here.

One additional note: We have run into this when the module that's being validated is called validationpathmodule.dll This module came from MS05-004 security update. This update was an interim fix that was in effect until a "full update" was released. With all latest updates for ASP.NET, this module is not needed so it can be removed. That is one of the workarounds for this situation, but only applies if the culprit is validationpathmodule.dll.