Since ORF 3.0, we sign every ORF binaries with Vamsoft’s Authenticode code signing certificate. This is great, because you can be sure that you have the original files from Vamsoft and no tampering was made with them. This practice is also encouraged by Microsoft and signed components probably will be a requirement for the Windows ‘Longhorn’ Server Certification Logo program.
When we released the Vamsoft Image Spam Agent extension for ORF, we signed the agent imgspamagent.exe binary as usually and let it go. Then we started receiving reports about timeouts running the agent and we did not have any idea why only specific servers were failing to run the agent and why the agent worked when they tried running it from command-line. And we were struggling to find an explanation until one of our clients (thanks!) found that the agent tries to connect to crl.verisign.com:80 every time it starts. Cool.
I mean, uh? Pardon me?
Obviously, the timeout was caused by the security settings of the affected servers—these servers blocked HTTP access to crl.verisign.com, thus the timeout error. But what makes the agent trying to visit VeriSign if we did not add such code to it?
Here is the trick: Windows was checking the Certificate Revocation List (CRL) of VeriSign to make sure that our certificate was not revoked, e.g. because our certificate was compromised and now bad people are trying to impersonate Vamsoft. The funny thing is that Windows does not check the CRL for regular ORF binaries, because they were written in Delphi, but the agent was written in .NET/C# and .NET programs behave differently.
According to this blog entry, if your .NET assembly is signed using Authenticode, every time the assembly is loaded, Windows performs the Certificate Revocation List check (depending on the user settings). This potentially means a couple of seconds wait to get your .NET program started or even more if the firewall prevents the program from accessing the CRL.
Now we know. If you sign it, it won’t run.
posted on October 29th, 2008 @ 07:41 pm GMT+0000
[...] http://blog.vamsoft.com/?p=48 if your .NET assembly is signed using Authenticode, every time the assembly is loaded, Windows performs the Certificate Revocation List check (depending on the user settings). This potentially means a couple of seconds wait to get your .NET program started or even more if the firewall prevents the program from accessing the CRL. [...]
posted on January 5th, 2009 @ 04:05 pm GMT+0000
[...] You can make sure a binary is from us by checking the digital signature on the file. In Explorer, right-click on the binary, select Properties. In the dialog displayed, there should be a Digital Signature tab and the name of the signer should be “Vamsoft Ltd.” (certificate is from Thawte Code Signing CA). Our .NET binaries are not signed for reasons outlined earlier (thus there is no Digital Signature tab), however these should still include vendor information on the Details tab. When in doubt, check the file with our tech support. [...]
posted on March 5th, 2010 @ 08:27 pm GMT+0000
[...] at any site that has a VeriSign Identity Protection logo, according to an Infoworld story. …Vamsoft Insider Sign It and It Won't Run… by Microsoft and signed components probably will be a requirement for the Windows Longhorn' [...]