Wednesday, January 23, 2008
« What's in my developer toolbox for 2008 | Main | First DR scare at the new office »

Lots of people are familiar with obtaining and installing SSL Certificates for hosting secure web sites, but the area of code signing seems less cohesive. I’ve compiled some notes I have on the process together in this blog post.

Yes, but who are you?

Reputable publishers of code signing certificates require some evidence that you are authorized with respect to the organization you wish to have named on your certificate. In my case, being able to produce the ASIC registration for my company was enough, YMMV.

This is subtle, but important.

  1. My company rego papers are credentials a Root CA (e.g Comodo, Verisign, Thawte, USERTrust etc) uses to trusts me.
  2. The user (implicitly) trust the Root CA by using an OS with their Certificate installed.
  3. Ergo, the user (indirectly) trusts me.

Macro projects in Microsoft Excel/Word/Visio/Access/etc

Once you have obtained your certificate, you are able to sign Macro projects in Office document templates by choosing Tools -> Digital Signature.

Your newly purchased certificate will appear in the list and by saving the project your template is signed. The difference is now the user is asked to trust you (as verified by the CA) and your code, rather than being asked to enable all macros.

Software distributed MSI packages

Signing MSI packages and CAB files is more visible than ever before in Windows Vista. This I think is a good thing, however I do worry that because there are a lot of unsigned installers out there that users may get the message that it’s not that important.

Once you have got your certificate from a CA, the process couldn’t be easier. There are a couple of ways to get signtool.exe, I usually have the Windows SDK on my machines which ships with it.  The command to sign ClassLibrary1.dll for example is: (assuming signing from a pfx, not the local cert store)

C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\signtool.exe sign /f My_Code_Signing_Cert.pfx /p L0ng5ecr3tp@ssw0rd /d name /du http://www.MyCompany.com /t http://timestamp.verisign.com/scripts/timestamp.dll ClassLibrary1.dll

The time stamping is important here, in that certificates expire. An external time stamp ensures that the assembly was signed while the certificate was valid.

.NET Assemblies

Technically, signing an assembly is not unlike signing an MSI. On one hand it is easier because you can do the signing from inside Visual Studio’s project properties

On the hand there is the concept of delay signing, where the actual private key is not available to the developer on a day-to-day basis.  This added security adds a layer of complexity that is frankly beyond the scope of this post. I will come back and dedicate a whole post to it some time :-)

Windows Logo Certification / WinQual

This is the only case I can think of where the vendor of the certificate matters. A certificate from VeriSign is required to prove your identity in the WinQual program, which is required for a Windows Logo certification. VeriSign has special pricing is on offer for members of Windows Quality Online Services site.  The $99 cert from VeriSign is required for WinQual membership, and is all you need if you already have a code signing certificate. The $399 cert is valid for both code signing and WinQual membership.