Browse All Articles > Digitally signing an installation file with a Postbuildevent
With the advent of Internet Explorer 9's enhanced SmartScreen Filter (also built into Windows 8, so on Win8 it affects users of other browsers) using Application Reputation, developers who make their software available for download online (particularly trial versions that you're using to try to gain new users with) have ever more reason to think about digitally signing their application and its installation file. By digitally signing your application, you reduce the likelihood that people will be scared off from trying your application because of the ominous warning that your software "is not commonly downloaded and could harm your computer," and the resulting extra hoops they have to jump through to actually run or install your application.
Digitally signing your software's application and installation files helps in five ways:
1) Instead of "unknown publisher," Windows will now report your name as "Verified Publisher" when someone runs the installer.
2) SmartScreen determines the reputation of your software (to decide whether it is "commonly downloaded") based not on the individual build of the installation file, but on all files that use the certificate. This means that if you have multiple applications, or multiple builds (because you're releasing the software with new features, or you have different variants of the application), all of them are summed together for Microsoft to decide the reputation score.
3) Even when your digital certificate is new and SmartScreen is still reporting that your software isn't commonly downloaded, a signed app gets a yellow border, rather than the red border of an unsigned app. If SmartScreen Filter is disabled, an unsigned app still generates a warning, whereas a signed app doesn't.
4) Digitally signing provides assurance that your software hasn't been tampered with after you released it; any attempt to tamper will generate an error when the altered file is run.
5) Some anti-malware software, such as Avast, will automatically block from running unsigned applications that have a low "file prevalence," requiring users to take special steps to enable the application.
Code signing certificates are now available for less than $100/year. You do need to provide proof that you are who you say you are, either as an individual or as a company; how much information you have to provide to the certification authority depends on how extensive your business presence is (at a minimum, you need to have a website of your own with a physical address that matches the address you want to use for your certificate). But the process is pretty simple. A great detailed description that I used is found at Jeff Wilcox's blog, which contains a link to purchase a certificate for as little as $73/year (5 years), at this writing. Note that it's beneficial to get an extended-life certificate, since at this time renewing a certificate causes you to get a brand-new certificate with no reputation, so you have to rebuild your reputation with each renewal. (Whether Microsoft will fix this in the future is unknown; don't bet on it.)
But for those of us using Visual Studio .NET (including Visual Basic, C#, and the other .NET languages) and creating Windows Installer .msi installation files, an important simplification step is missing. Jeff Wilcox's blog describes how to get the certificate, install it on your machine, and use it with the SignTool wizard that Microsoft provides with Visual Studio. But that means that every time you build your installation file, you have to manually walk through the wizard, specifying files and titles. That gets tedious, and prone to error. Far better to do the signing as a post-build event, defined in both the application project and the deployment project. The post-build event in the application project signs the executable file (.exe); the post-build event in the deployment project signs the installation file (.msi). It's beneficial to sign both.
Signing your installation file is done with SignTool, provided by Microsoft. It is a 32-bit application, so its location depends on whether you're using a 32-bit or 64-bit version of Windows, as well as what version of Visual Studio you are using:
32-bit Windows: C:\Program Files\Microsoft SDKs\Windows\<version>\Bin
64-bit Windows: C:\Program Files (x86)\Microsoft SDKs\Windows\<version>\Bin
<version>= V6.0A for VS 2008, V7.0A for VS 2010 V8.0A for VS 2012
For a complete listing of the options available for SignTool, see here. A list of macros, which start with a $ sign and you can use to define names of files and folders, is available when you open the dialog box for pre- and post-build events in VS. However, I have found that using the following options works well for me. I'm listing one option on each line, so I can describe it; at the bottom, you'll see a full command line put together.
sign command to actually sign the file
/d "Description" Description of your application; optional
/du "http://descriptive.url.com" URL for more information on your application
/t "http://timestamp.somewhere.com" URL for your certificate's timestamp server
$(TargetPath) Executable file to be signed, in your development folder
$(ProjectDir)obj\$(ConfigurationName)\$(TargetFileName) Executable file to be signed, in the folder that's used to build the deployment package
$(BuiltOuputPath) Installation file to be signed (note the misspelling: it really is "Ouput", not "Output", for the middle word)
Since this is a command line, any parameter with a space needs to have quote marks around it. In fact, I recommend using quote marks around every parameter; there's no harm, and sometimes characters other than space can cause problems. (I couldn't get /t to work until I surrounded the URL with quotes, even though it had no spaces and worked on a regular command prompt line.)
There are several ways to specify the certificate to be used. If you only have one signing certificate on your computer, then no specification is required; SignTool will automatically find and use the certificate (assuming you've put it in the certificate store). If you have more than one signing certificate, you can use one of the following methods:
/a Select the best signing certificate automatically. SignTool chooses for you.
/f xyz.pfx Use a .pfx file that contains a certificate. This can be output from the certificate store (see Jeff Wilcox's Step Five). If you used a password to protect the .pfx file, specify it with /p password. Note, though, that this requires putting your password in plaintext in the postbuildevent property, which is not terribly secure. Use this only if you have tight security on your computer. If your .pfx file doesn't contain the private keys, see the /csp and /k options in Microsoft's SignTool description.
/i issuer Specify the certificate by using part or all of the issuer's name.
/n subject Specify the certificate by using part or all of the subject's name (that is, who the certificate is issued to: your company or personal name, as shown on the certificate)
To set up a post-build event in the application project, go to the project's Properties, Compile tab, and click on Build Events.... Enter the command in the Post-build event command line.
To set up a post-build event in the deployment project, highlight your deployment project in the Solution Explorer and select the PostBuildEvent property in the Properties window.
Some example commands:
Now you have a higher-credibility distributable, so potential users are less likely to be scared off, with no extra effort after the initial setup.
Note that having a certificate does not immediately turn off the "not commonly downloaded" warning. You'll have to wait for enough people to install your application (or otherwise use your certificate in ways that Microsoft logs) before the warning will go away. But even during that time, having "verified publisher" next to your name provides substantial reassurance to users that you're not a malicious or fly-by-night developer. And that's likely to translate into higher usage and sales of your software, as well as fewer calls asking why your software has a virus (a common misconception caused by the "may harm your computer" wording of SmartScreen's message). Microsoft also suggests signing up for the Windows 7 logo program to improve your reputation.
Moderate cost and minimal effort can get you the trust you deserve. Now is the time to take the plunge.
Digitally signing your software's application and installation files helps in five ways:
1) Instead of "unknown publisher," Windows will now report your name as "Verified Publisher" when someone runs the installer.
2) SmartScreen determines the reputation of your software (to decide whether it is "commonly downloaded") based not on the individual build of the installation file, but on all files that use the certificate. This means that if you have multiple applications, or multiple builds (because you're releasing the software with new features, or you have different variants of the application), all of them are summed together for Microsoft to decide the reputation score.
3) Even when your digital certificate is new and SmartScreen is still reporting that your software isn't commonly downloaded, a signed app gets a yellow border, rather than the red border of an unsigned app. If SmartScreen Filter is disabled, an unsigned app still generates a warning, whereas a signed app doesn't.
4) Digitally signing provides assurance that your software hasn't been tampered with after you released it; any attempt to tamper will generate an error when the altered file is run.
5) Some anti-malware software, such as Avast, will automatically block from running unsigned applications that have a low "file prevalence," requiring users to take special steps to enable the application.
Code signing certificates are now available for less than $100/year. You do need to provide proof that you are who you say you are, either as an individual or as a company; how much information you have to provide to the certification authority depends on how extensive your business presence is (at a minimum, you need to have a website of your own with a physical address that matches the address you want to use for your certificate). But the process is pretty simple. A great detailed description that I used is found at Jeff Wilcox's blog, which contains a link to purchase a certificate for as little as $73/year (5 years), at this writing. Note that it's beneficial to get an extended-life certificate, since at this time renewing a certificate causes you to get a brand-new certificate with no reputation, so you have to rebuild your reputation with each renewal. (Whether Microsoft will fix this in the future is unknown; don't bet on it.)
But for those of us using Visual Studio .NET (including Visual Basic, C#, and the other .NET languages) and creating Windows Installer .msi installation files, an important simplification step is missing. Jeff Wilcox's blog describes how to get the certificate, install it on your machine, and use it with the SignTool wizard that Microsoft provides with Visual Studio. But that means that every time you build your installation file, you have to manually walk through the wizard, specifying files and titles. That gets tedious, and prone to error. Far better to do the signing as a post-build event, defined in both the application project and the deployment project. The post-build event in the application project signs the executable file (.exe); the post-build event in the deployment project signs the installation file (.msi). It's beneficial to sign both.
Signing your installation file is done with SignTool, provided by Microsoft. It is a 32-bit application, so its location depends on whether you're using a 32-bit or 64-bit version of Windows, as well as what version of Visual Studio you are using:
32-bit Windows: C:\Program Files\Microsoft SDKs\Windows\<version>\Bin
64-bit Windows: C:\Program Files (x86)\Microsoft SDKs\Windows\<version>\Bin
<version>= V6.0A for VS 2008, V7.0A for VS 2010 V8.0A for VS 2012
For a complete listing of the options available for SignTool, see here. A list of macros, which start with a $ sign and you can use to define names of files and folders, is available when you open the dialog box for pre- and post-build events in VS. However, I have found that using the following options works well for me. I'm listing one option on each line, so I can describe it; at the bottom, you'll see a full command line put together.
sign command to actually sign the file
/d "Description" Description of your application; optional
/du "http://descriptive.url.com" URL for more information on your application
/t "http://timestamp.somewhere.com" URL for your certificate's timestamp server
$(TargetPath) Executable file to be signed, in your development folder
$(ProjectDir)obj\$(Configu
$(BuiltOuputPath) Installation file to be signed (note the misspelling: it really is "Ouput", not "Output", for the middle word)
Since this is a command line, any parameter with a space needs to have quote marks around it. In fact, I recommend using quote marks around every parameter; there's no harm, and sometimes characters other than space can cause problems. (I couldn't get /t to work until I surrounded the URL with quotes, even though it had no spaces and worked on a regular command prompt line.)
There are several ways to specify the certificate to be used. If you only have one signing certificate on your computer, then no specification is required; SignTool will automatically find and use the certificate (assuming you've put it in the certificate store). If you have more than one signing certificate, you can use one of the following methods:
/a Select the best signing certificate automatically. SignTool chooses for you.
/f xyz.pfx Use a .pfx file that contains a certificate. This can be output from the certificate store (see Jeff Wilcox's Step Five). If you used a password to protect the .pfx file, specify it with /p password. Note, though, that this requires putting your password in plaintext in the postbuildevent property, which is not terribly secure. Use this only if you have tight security on your computer. If your .pfx file doesn't contain the private keys, see the /csp and /k options in Microsoft's SignTool description.
/i issuer Specify the certificate by using part or all of the issuer's name.
/n subject Specify the certificate by using part or all of the subject's name (that is, who the certificate is issued to: your company or personal name, as shown on the certificate)
To set up a post-build event in the application project, go to the project's Properties, Compile tab, and click on Build Events.... Enter the command in the Post-build event command line.
To set up a post-build event in the deployment project, highlight your deployment project in the Solution Explorer and select the PostBuildEvent property in the Properties window.
Some example commands:
"C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\signtool" sign /a /d "ElrondCT's Wonderful App" /du "www.wonderfulapp.com" /t "http://timestamp.comodoca.com/authenticode" "$(ProjectDir)obj\$(ConfigurationName)\$(TargetFileName)"if $(ConfigurationName) == Release "C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\signtool" sign /a /d "ElrondCT's Wonderful App" /du "www.wonderfulapp.com" /t "http://timestamp.comodoca.com/authenticode" "$(TargetPath)""C:\Program Files\Microsoft SDKs\Windows\V6.0A\Bin\SignTool" sign /a /d "ElrondCT's Wonderful App" /du "www.wonderfulapp.com" /t "http://timestamp.comodoca.com/authenticode" "$(BuiltOuputPath)""C:\Program Files\Microsoft SDKs\Windows\V7.0A\Bin\SignTool" sign /i COMODO /t "http://timestamp.comodoca.com/authenticode" "$(BuiltOuputPath)"Now you have a higher-credibility distributable, so potential users are less likely to be scared off, with no extra effort after the initial setup.
Note that having a certificate does not immediately turn off the "not commonly downloaded" warning. You'll have to wait for enough people to install your application (or otherwise use your certificate in ways that Microsoft logs) before the warning will go away. But even during that time, having "verified publisher" next to your name provides substantial reassurance to users that you're not a malicious or fly-by-night developer. And that's likely to translate into higher usage and sales of your software, as well as fewer calls asking why your software has a virus (a common misconception caused by the "may harm your computer" wording of SmartScreen's message). Microsoft also suggests signing up for the Windows 7 logo program to improve your reputation.
Moderate cost and minimal effort can get you the trust you deserve. Now is the time to take the plunge.
Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.
Comments (1)
Commented: