You thought to yourself, “Self, I think I should sign all of my dll’s with my authenticode certificate!”. Why ,not? It would make the application appear secure with digital signatures and all. I can use publisheridentity attributes for security and all should be well. Right?
The issue comes to the way the .NET loader handles the assemblies, especially when offline.
See, the .NET Framework will go out and verify each DLL’s certificate against the CRL. This requires making sure the CRL list is up to date and can incur an overhead of up to a couple of seconds. If you have a large number of dll’s, which many projects do, this can be quite the expensive task. What happens if your offline, well, it still tries to verify the signatures.
So, will the application run if it can’t verify the signatures? Yes. Yes it will.
Now you ask, “What do I gain by signing my dll’s?” If you are a vendor/publisher, you need it for Vista compliance.
Otherwise, I suggest you simply sign your EXE alone. There is a small performance hit, but if your application requires Elevation at least your customers will see the pretty name for your application and company instead of the dreaded “Unidentified Application” prompts.
You can take it from me, be careful of the performance impacts of authenticode signing your .NET assemblies. (Yes, it even checks them if they are GAC’ed.)