Atmosera

Code Signing – It’s Cheaper and Easier than You Thought

One of the things I’ve always wanted to do, but never got around to, is to figuring out how to sign my code. Like most developers, I never really worried about code signing until Vista came along. Maybe it’s just because I’m completely anal retentive, but I always felt a little guilty when my applications or installations that need administrator privileges show the dreaded UAC Cancel/Allow dialog:

To me, that just looks a bit unprofessional. I don’t want to be known as “Unidentified Publisher.” The main reason small shops or independent developers don’t sign their applications is because the cost of a code signing certificate, sometimes called an ID, has always been very expensive. Checking VeriSign right now, they want $499 USD for a one year certificate and $1,293 USD for a three year certificate. For that much money you can get pretty nice laptop. Thus began my quest to see if I could get a code signing certificate for a reasonable price.

In this blog entry I’ll show where I got a reasonably priced certificate and how to get your binaries and installs signed correctly. As I was reading how to make everything worked, there was no one place that showed all the parts from buying a certificate, to getting it on your machine, to getting you code signed in the real world. Hopefully this will help you out if you want to or are required to code sign.

Searching for code signing certificates turns up numerous companies that will sell you a certificate with prices ranging from $179 USD to $499 USD per year. They all offer cheaper options if you buy three year certificates, but they still cost more than a single developer probably wants to pay. Fortunately, the day I thought about getting a code signing certificate, Omar Shahine mentioned that TUCOWS, (I’m so old I remember the original “The Ultimate Collection of Winsock Software” web site!), is reselling Comodo digital certificates at $80 USD per year at their author specific web site. Even better is the three year price of $195 USD. That was price I could justify spending with the Robbins household CFO, AKA my wife.

After you purchase the certificate, you have to prove who you are. That’s the whole reason it’s called a “trusted certificate” in the first place. If you want the certificate in your name alone, you’ll need to fax them a copy of your driver’s license that shows the address you specified in the sign up pages. If you want a company name on the certificate you’ll need to fax Comodo copies of your company’s articles of organization and a business tax license. As I wanted my certificate to say “John Robbins/Wintellect” I faxed three documents and Comodo happily issued a certificate.

I had some trouble with registration process at Comodo. Make sure you add https://secure.comodo.net to the list of trusted sites in Internet Explorer so they can properly get you registered and install their trusted root certificate on your computer. You’ll have to use the machine you registered with Comodo to retrieve you certificate. One thing that Comodo does not make clear is that they expect you to register at http://support.comodo.com to ensure you really sent in the request and interact with them if you need to ask questions. Finally, make sure to set any spam filters you are using to allow mail from comodo.com through so when you get your certificate issued, you’ll actually get the mail. [Edit: 1/17, I want to make clear that the certificate from Comodo is trusted on all computers. You only need to install Comodo’s certificate on the machine you are using to buy your certificate.]

When you get the email giving you the download address, you’ll click on the link and download your certificate into the certificate cache on the machine. Since you’ll want the certificate in file form to make signing easier, you need to get it out of the certificate store. On a Vista computer, the first step is to start the Certificate Manager snap-in, by running “certmgr.msc.” The certificate downloaded from Comodo is in the PersonalCertificates section and the issuer is UTN-UserFirst-Object.

Right click on the certificate and select All Tasks, Export… That will bring up the Certificate Export Wizard. The first decision you’ll have to make is if you want to export the private key information with the certificate. In nearly all cases, you’ll need to choose “Yes, export the private key.” The second decision is what data you want included in the Personal Information Exchange (.PFX) file you’re exporting. What I chose to do was the following:

This allows you to have a complete certificate in the .PFX file. I chose to leave the private key in the Certificate Manager so I could export the key in multiple ways, which I’ll discuss why in a bit. After clicking the Next button, you’ll have to provide a password for the certificate. As I’m using Vista, that’s required. A few things I read on the web said that with XP you could export a .PFX file with no password, which seemed quite dangerous to me. It goes without saying that you’ll want to be careful with the password and actual .PFX file.

Once you’ve got the .PFX file on disk, it’s time to sign something and that’s where SIGNTOOL.EXE comes into play. Visual Studio 2008 Team Editions includes the latest Platform SDK so all you need to do is start a Visual Studio 2008 Command Prompt to get the path environment variable initialized. All that does is run the <Visual Studio Installation Directory>VCvcvarsall.bat batch file. If you do not have a Team Edition of Visual Studio, you can download the Vista Platform SDK here.

In the command prompt, type the following command to sign all the files you want to sign: (all one line)

signtool sign /f YourFile.pfx /p <password>
/t http://timestamp.comodoca.com/authenticode <files>

If you’re signing a .MSI file, also add the /d command line option to specify the description of your install program so the user will see that instead of the temporary name Windows Installer actually uses for the installation. Once you’ve signed your binary, you’ll look as professional as you the big guys:

If you are curious what DbgChooser is, see my January 2000 Bugslayer column in Microsoft System’s Journal.

There are obviously more command line options to SIGNTOOL.EXE you can read about in the documentation. Once you’re signing files, you probably want to verify a file is signed properly. Fortunately, SIGNTOOL.EXE has the verify option you can use to check.

signtool verify /pa <files>

Manually signing your binaries is certainly not going to scale so you’ll want to automate the process. For signing .NET assemblies I found an article that talks about how you can use a .PFX file in place of the strong name key (.SNK) file most of us use. As the article says, you’ll want to make sure to export the .PFX file without any other certificates by ensure you do not check “Include all certificates in the certificate path if possible.” Following all the steps in the article, I copied the exported key over to a new machine, and added the .PFX file. Visual Studio prompted me with the Import Key File dialog asking for the .PFX file password. Typing in the password and clicking OK appeared to work. The problems started when I tried to compile the application. I got the Import Key File dialog again asking for the password, but entering the correct password just got me a message box titled “Error importing key” with the message “Object already exists.” Looking through the Certificate Manager, I couldn’t find a copy of my certificate anywhere. Wondering if this was an issue because I was running Visual Studio as a regular user, I elevated Visual Studio to have administrator rights and still encountered the same error.

As I started reading about others having similar problems and quickly falling into the bottomless pit of acronyms like OPENSSL, SHA1, PEM, SPN, PVK, and PCKS12, I admit that I gave up. I just want to get my binaries signed, not have to become a super certificate ninja. Since I knew SIGNTOOL.EXE worked, I just needed to wrap it up in an MSBUILD. Looking at the MSBuild documentation, I found the perfectly named SignFile that’s part of MSBuild. Sadly, it only works on Portable Executable (PE) files and won’t sign your .MSI files. Equipped with the Exec task in MSBuild, you can pretty much get anything wrapped up quickly:

Since writing MSBuild tasks derived from ToolTask, it’d take about five minutes to make SIGNTOOL.EXE a little easier to use on a larger project.

Now with the reasonably priced digital certificates through TUCOWS, you should take a hard look at signing your binaries and installations. It’s not required, but it sure looks better on Vista if you do.

Update May 15, 2008: Microsoft lost the link to my column so I changed the Debugger Chooser link to download the code for that issue of MSJ.

John Robbins

Next Security Implications Of Services Impersonating Callers »

Previous « Catching Up During the Holidays

View Comments

Anonymous says:

December 21, 2007 at 8:29 am

Code signing
Anonymous says:

December 21, 2007 at 9:26 am

You're not that old. Although, I guess by Internet years having been around since 1993 makes Tucows "old" which may make people who remember both the site, and what the acronym stands for "old" as well. Glad you found what you were after and thanks for the excellent tutorial.
James from Tucows
Anonymous says:

December 21, 2007 at 12:06 pm
Anonymous says:

December 21, 2007 at 6:01 pm

I don't have a driver's license - how do they feel about passports?
jrobbins says:

December 22, 2007 at 4:43 pm

Kevin,
Good question. I'd send a support request to the folks at Comodo (https://support.comodo.com/). They should be able to get something worked out for you.
Hope it helps!
-John
Anonymous says:

December 22, 2007 at 11:54 pm

Should you sign all your .dlls? Or just your main .exe?
jrobbins says:

December 23, 2007 at 3:15 am

Harold,
It can't hurt to verify all your PE files.
-John.
Anonymous says:

December 24, 2007 at 12:00 pm

John,
the link "http://www.microsoft.com/msj/0100/bugslayer/bugslayer0100.aspx" is broken.
Anonymous says:

December 24, 2007 at 8:54 pm

It doesn't matter how cheap and easy code signing is, I want to boycott it on principle. Not because of the price, although even 80$ a year is much for a single autogenerated number.
The code signing scheme itself is useless. Anyone can request or share a public a certificate. So mal- and spyware still can destroy your computer, but now 'approved and certified' by Verisign/Microsoft.
The only thing it's good for is annoying end users and (independent) developers.
Anonymous says:

December 27, 2007 at 4:06 pm

BillGoates, you just don't get it. Why do cars have license plates and police have badges? These don't stop people from speeding thru school zones or impersonating cops. In fact, nothing actually prevents a real cop from going berserk at any moment.
What they do, however, is act as deterrents which form part of a larger security process. A car without plates will draw suspicion; a car with plates which appears suspicious can be checked to see if the plates were stolen. From insurance ID cards to voter registration cards, forms of official identification exist to provide "reasonable" assurance that someone is who you expect them to be, no more and no less.
That's not "useless" because it's a far cry from total anonymity. Why do you suppose that for 99.999% of all spam, the true sender is obscured? It's a simple fact that malicious parties don't like to be identifiable. Sure, there will always be suicide bombers who don't mind letting you know their name, right before they blow you up, but how many suicide bombers exploded today? On the other hand, how many hot checks were written today? Is it totally "useless" for Wal-Mart to ask for ID?
Code signing tells you that you are executing code from someone whose identity has been checked. More importantly, it tells you that the code has not been corrupted since it was signed, neither by virus infection nor by faulty file transfer. Change a single byte in a signed file and it immediately renders the signature broken.
Non-malicious software could be buggy and "destroy your computer" the same as malware, but even if you don't trust a signature to represent the author's identity upon initial receipt of some code, once you have verified for yourself that the code is safe, the signature tells you later that the code hasn't been tampered with.
10 years ago, the industry was skeptical of code signing. Today, code signing is widely used in Java, Linux, and other non-Microsoft environments. Apple's latest Mac OS X (Leopard) fully supports code signing and delivers virtually all of its components as signed by Apple. Certificate issuers from Thawte to VeriSign have repeatedly demonstrated prompt and responsible revokation of certificates obtained for fraudulent purposes. From Safari to Firefox and Opera (all shipped signed), the entire industry has embraced code signing -- not as a total solution to anything, but as part of the solution to many things.
If you're a small developer (which implies you're working with a relatively small user population), you can always self-sign for $0. The catch is that your users must install your certificate authority in their trusted store, a one-time step. Presumably they would do this if they trust you, and presumably they would only trust you if they are satifisfied that they can identify you. The $80 saves them a little hassle by having Comodo do a reasonable check of your identity and issue a certificate from an authority which is pre-trusted by the default installation of common operating systems.
Sure, this system hasn't stopped people from forming malicious companies which were actually and legally named "Click Yes to Continue" but how long do you think they got away with it? About as long as it would take to notice a car without plates or a cop without a badge.