The last step of this process is to sign the .msi file that you created, so that users won’t get any messages from Windows when they download and install it. The signing technology that is used is known as Authenticode.
Before I get into the mechanics – which I think are pretty simple – it would be good to read the following, which covers not only the mechanics of code signing, but also the logistics and the organizational approach.
You will also need to download the code signing tools. Some of the MSDN docs are out of date and point you to Authenticode toolkits for Internet Explorer, which are no longer around.
The tools that you need can be found in these two SDKs (you only need one):
Note that these steps are sufficient to test code signing. When you get around for code signing for real, you will need to use appropriate organizational policies. The Best Practices guide mentioned earlier is a good reference, and you might also want to read:
Okay, now that that’s out of the way. To do the test signing, follow the instructions here:
In step 3 of signing, select the .msi file that you want to sign. Make sure you select the right container on step 12.
On the timestamp page, you should enter a URL (the “best practices” guide explains why, but basically it allows the signing to remain valid after the certificate expires). VeriSign runs a free timestamp server at:
Once the signing process has completed, you can look at the file properties, and you should see a “Digital Signature” tab with information about the certificate you used.