Code signing performance problems with Certificate Revocation chec
- From: AWJ <AWJ@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 27 Feb 2007 09:40:25 -0800
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
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
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
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.
- Prev by Date: Re: A cryptography solution for a client/server winforms app
- Next by Date: Re: Program crashes when running accross network, but fine when on pc
- Previous by thread: OTP Implementation
- Next by thread: Re: Program crashes when running accross network, but fine when on pc