通过

Bypassing the CRL Check on CLR Startup

  • 项目

Ever wonder why your managed service may be slow to start up at times?  The Microsoft assemblies that you depend on in your managed service are signed with both a strong name signature and an Authenticode signature.  Authenticode signatures allow for the identity of the assembliy to be verified by chaining the certificate to a trusted root.  In addition, it also allows for certificates to expire and be revoked if they are compromised.  This checking can cause problems for your service if it is installed on a machine that does not have access to the internet.  The reason is that when the CLR loads an assembly which has an Authenticode signature, it tries to verify it by reaching out on the internet to make sure there is a full chain of certificates back to the issuing authority as well as validate the certificate has not been revoked.  If you do not have internet connectivity, this can cause a delay of several seconds.

If you are designing an application or a service that uses an Authenticode signed assembly, and you are fairly certain that you do not need to pay the performance penalty, you can bypass this check through your configuration file:

 <configuration>

     <runtime>

         <generatePublisherEvidence enabled="false"/>

     </runtime>

 </configuration>

This will prevent the CLR from verifying the Authenticode signatures of any assembly loaded by the application.  The assemblies will no longer receive Publisher evidence or PublisherIdentityPermission, but in most cases, you probably don't care about that anyway.  An example of this happens when you use the SQL Server Compact Edition assemblies.  This is something I have researched several times over the years, so it seems worthy of being elevated to my BLOG.  Enjoy!

Comments

  • Anonymous
    August 14, 2011
    Is it possible to use another chain of trust and CRLs? For example distributing certificates from from our own internal CA that then can get revoked by distributing a CRL?

  • Anonymous
    August 15, 2011
    For assemblies that you sign, yes.  For assemblies signed by third parties (like SQL Server Compact Edition), no since you don't have control over their chain to the root CA.