Hello all.
After talking to Microsoft about this behavior, they were able to provide me with more information about the behavior we are seeing. Thawte has no control over this behavior, so you will probably continue to see the problem, even after their ISP backbone issue is corrected. Unless ofcourse you use the workaround. Read on for more information about that.
Internally, the .NET framework is using the WinTrust() APIs to verify a digitally signed assembly. Part of this validation requires downloading the CRL (certificate revocation list) from the Certificate provider (Thawte). When the CLR (Common Language Runtime) loads an Authenticode signed assembly and is unable to reach the CLR distribution point, it records the failure as an inability to provide the assembly evidence that it was Authenticode signed. So the assembly is allowed to load, but is not marked as being digitally-signed.
This behavior is by design.
The delay occurs because of the behavior of the WinTrust() APIs .The timeout for CRL retrievals is 15 seconds. The timeout settings for this API is not user configurable.
The CLR will not indicate any error nor throw any security exception when verifying a signed assembly if the CRL distribution point cannot be reached. An error here from WinVerifyTrust() just prevents the assembly from being marked as Authenticode-signed. (Note that this does not apply to assemblies loaded thru the Internet Explorer hosting interface).
You could manually download the CRL, and install it on your system. But the CRL is valid only for 10-15 days, so unless your system is able to update the file after this time, you will run into the same problem again.
Microsoft recommended the same workaround that has been described previously.
The workaround they presented was to disable Certificate Revocation checking by disabling this option in Internet Explorer.
1. Launch Internet Explorer and go to Internet Options
2. Click on the Advanced tab
3. Scroll down to the "Check for publisher's certificate revocation" checkbox and uncheck it.
By disabling the CRL checking using the IE options, you are not exposing yourself to a security threat because this check is not working for you in the first place. The reason why this problem is showing up is because your network settings are not allowing the Windows Public Key Infrastructure (PKI) system to access the CRL.
I’ll document this information on our website to make it easier to find.
Hope this explains things.
Bilal Durrani
NI