Skip to main content
Thoughts from David Cornelius

Category

Have you ever downloaded an application and had Windows try to prevent you from opening it? Many times that will slow or stop malware from getting onto your computer but for contract programmers that distribute a variety of custom-built applications to clients, it can be annoying to them as they struggle to keep the download from being quarantined or deleted by their web browser or anti-virus program. Often, the download is halted simply because the application is not recognized and the publisher is unknown. Fortunately, there's a solution that doesn't cost too much and provides not only peace of mind for the person attempting to install your software but also smooths the process, eliminating warnings.

Code signing digitally marks your application with a certificate that is verified with a publicly known entity that ensures no one but you has modified your code and that you are a known and trusted entity. It doesn't guarantee you won't intentionally or unintentionally pass a virus through but as more and more copies of your signed applications get installed, the trust factor goes up and the warnings go away.

One popular place to get code-signing certificates is K Software. For less than $100 per year, an individual or organization can use a digital certificate to sign all their code. Once verified, downloaded and installed, the certificate's private key can be exported to a local file, assigned a password, then used with a code-signing tool to apply the digital signatures. After a file is signed, its properties show a Digital Signatures tab with details to verify a certificate has been applied.

It takes a little configuration but is easily automated once you have the tools in place. My code-signing tool of choice is the Windows SDK. It's free, quick to download and install, and provides a robust command-line app, signtool.exe, with many options. To sign a file with the Windows SDK, several command-line arguments must be given:

signtool sign /f "MyCert.pfx" /p "MyPassword" /fd sha256 /td sha256 /tr http://timestamp.sectigo.com "MyFile.exe"

Here's an explanation of them:

  • sign: this is the command given to the sign tool; there are other commands you can give it, such as verify, timestamp, and even remove.
  • /f "MyCert.pfx" /p "MyPassword": this tells the sign tool the private key file you exported and the password you assigned to digitally sign your file.
  • /fd sha256: this instructs the sign tool to use a strong hashing algorithm.
  • /td sha256 /tr http://timestamp.sectigo.com: signatures should have a hashed time-stamp applied.
  • "MyFile.exe": the final parameter is the actual file to be digitally signed. It doesn't have to be an .EXE, it can be a .DLL, a .ZIP, or any other file.

I typically add the Windows SDK folder containing signtool.exe to the system path so that I can call it from anywhere without explicitly spelling out the full path.

Automating code signing with Delphi

This command can be easily put into a batch file for automating distribution of applications and support files. If you use Delphi, you can use a project's Build Events to have your compiled apps automatically signed as part of the build process right within the IDE. Build events are specific to the build configuration; I typically assign the signing operation only when the build configuration is set to Release mode and leave it off for debug builds. One nice thing about using it within the Delphi environment is that special environment variables are available. This means that instead of writing a custom sign script for each project in order to name the file to sign, I can simply replace the filename with "$(OUTPUTPATH)" which substitutes the full path and filename of the compiled module as it hands it off to the sign tool.

Automating code signing with InnoSetup

InnoSetup is a popular installer builder and also supports using a sign tool. Only one sign tool can be used per script, however you may have many different installation packages to support, possibly using different sign tools. So what InnoSetup does is allow you to specify one or more sign tools and give them a name. Then you use the name of the sign tool to use in your script. To set this up, select Configure Sign Tools... from InnoSetup's Tools menu. When the Configure Sign Tools dialog box comes up, click the Add button and enter a unique name for the signtool and click OK. Then it prompts for the command-line of the sign tool. Using the Windows SDK signtool command as described above, the syntax is very similar to what we saw before with one exception. For the last parameter, the filename of the file to sign, put $f instead and InnoSetup replaces that with the actual installer filename generated by InnoSetup.

Once the sign tool is configured in InnoSetup, using it in a script is as simple as assigning the new unique name of the configured sign tool to the the key name, Signtool, in the [Setup] section of your InnoSetup script.

Now that your application and the installer are signed, you can distribute your applications over the internet without the dreaded "Unknown Publisher" warning. At first, Windows will still warn and try to prevent your application from being installed but as more and more installations take place, the Windows SmartScreen filter gets more comfortable with allowing applications from you to be installed. Eventually, your signed apps will feel like they are being published by big, reputable software houses--and your customers will no longer be worried by warnings of untrusted code on their machines.

Add new comment

The content of this field is kept private and will not be shown publicly.