Code signing performance problems with Certificate Revocation chec



With the latest Microsoft OS's such as Vista, Logo compliance requires all
installers, assemblies, EXE's and DLL's to be digitally signed. This is
causing problems in various scenarios as Windows will check the certificate
revocation status at install and run time if the machine thinks it has
internet access but if it then fails to get access to
http://crl.microsoft.com/ it causes big performance problems. There are
various ways to try and counteract this which I will list below but so far
for a server based application which runs without a user being logged on I
have not found a good solution and am looking for some help as information on
this appears to be very sparse.

If the server can gain access to http://crl.microsoft.com/ without any
authentication (i.e. a proxy server etc in the way) things are probably ok
but in many corporate environments this is not the case. Incidentally if the
machine knows it can't get access to the internet e.g. you take the network
cable out of it none of these checks happen and the problem is solved (not
very useful scenario though!)

Ways to resolve I have seen suggested along with comments.
1.In Internet Explorer
Select Start»Control Panel.
Double-click Internet Options.
Select the Advanced tab.
In the Security section, uncheck the Check for publisher's
certificate revocation option.

This may be ok for the current logged in user but for a server application
that runs without a logged on user I don't think this is going to work. I
guess it may do if all the applications services run under an account where
this has been set does anyone have any comments on this?

2 Changing the registry
In addition the above, it is possible to programmatically set the CRL
verification. When the "Check for publisher's certificate revocation" is
unchecked, a setting in the registry is changed. To turn off CRL
verification, set
HKCU\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust
Providers\Software Publishing\State from 0x00023c00 to 0x00023e00. To turn
CRL on again, reset the State key to 0x00023c00.

Again this is only specific to the current user as the previous option.

3 Another option which sounded promising
Add this text in your hosts file under system32\drivers\etc

127.0.0.1 crl.microsoft.com

However under testing this appeared to make things take 2-4 times longer
rather than improve things.

The background to this problem is below if you are not familiar.
This behaviour will occur with any .NET assembly that is digitally signed or
code-signed. Digital signing is also referred to as code signing. Code
signing a .NET library is strongly recommended by Microsoft

Code signing of assemblies makes components tamper-proof and ensures that
you know the identity of the component publisher.

The reason why this problem is occurring is because of the mechanism used by
the .NET Common Language Runtime (CLR) to verify code-signed .NET assemblies.
Part of the verification process requires an online look-up to check whether
the certificate with which the assembly is signed has been revoked and is no
longer valid. Windows does this by downloading a CRL (Certificate Revocation
List). The first time a code-signed assembly is loaded by the .NET CLR, the
CRL is downloaded from the certificate provider's server and cached on the
system.

When the .NET CLR loads a code-signed assembly and is unable to reach the
CRL distribution point, it records the failure as an inability to provide the
assembly evidence that it was code-signed. So the assembly is allowed to
load, but is not marked as being digitally signed. There is a 15 second delay
for CRL retrievals. This is how long the CLR will keep on re-trying to
download the CRL before it finally times out. So the delay in loading the
..NET assembly occurs because Windows is unable to download the CRL and keeps
trying to download it for 15 seconds before timing out. Complex applications
have hundreds of these assemblies so the time delay can be quite noticeable.

.



Relevant Pages

  • Code signing performance problems with Certificate Revocation chec
    ... installers, assemblies, EXE's and DLL's to be digitally signed. ... it is possible to programmatically set the CRL ... When the "Check for publisher's certificate revocation" is ... ..NET assembly occurs because Windows is unable to download the CRL and keeps ...
    (microsoft.public.dotnet.framework.setup)
  • Re: Assembly conversion to Pocket Pc format
    ... string strfilename = ... for .NET assemblies, i.e. it is simply passing them through unmodified. ... rather I want to download from HTTP or HTTPS. ...
    (microsoft.public.dotnet.framework.compactframework)
  • RE: Intermittent MissingFieldException
    ... Microsoft Online Support ... |> asp.net application's private bin path. ... |> for those assemblies. ... |> | Attempting download of new URL ...
    (microsoft.public.dotnet.framework.aspnet)
  • Intermittent MissingFieldException
    ... log4net assembly is referenced thus: ... because the problem never occurs with our other assemblies. ... because the Infrastructure assembly wasn't loading properly. ... Attempting download of new URL ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: re:using System.DirectoryServices.dll assembly
    ... You need the assemblies full name: ... > specific parse error details and modify your source file ... Attempting download of new URL ... > Posted Via Usenet.com Premium Usenet Newsgroup Services ...
    (microsoft.public.dotnet.languages.csharp)