Automating Code Signing of Windows Executables

Posted January 6th, 2006 by kyle

Introduction

Digital signatures provide a way to determine the identity of the creator of a document, know that the document has not been altered since it was signed, and verify when it was signed. Installation and application executables can also be digitally signed (also called code signing). Many software vendors have been code signing their application files for years, but for those who have been lax about it, the release of Windows XP Service Pack 2 provides a major impetus to begin doing so.

Before XP SP2, to most users, there was no obvious difference between a signed and unsigned executable. Under earlier versions of Windows, an unsigned program that was downloaded would run without any warning at all or would show the same warning message as a signed executable. But with XP SP2, when downloading a program with Internet Explorer and choosing to open it (or even if saved to a file and later opened via Windows Explorer), this dialog will be displayed for an unsigned executable:

No Certificate

Compare this to what the user sees for a signed executable under XP SP2:

With Certificate

A warning dialog is still displayed, but it’s much less ominous and a hyperlink to your digital certificate is provided, giving the user more confidence that the file is safe to download and run.

Unfortunately, there are some potential pitfalls when incorporating code signing into the software development process, some of the details are not obvious, and there doesn’t seem to be a single document that describes all the necessary steps. That is what this article attempts to provide.

The Tedious, Manual Stuff

Most of the work to sign your executables is (thankfully) a one-time, manual setup process.

1. Obtain the Code Signing Tools

First, you need to obtain the necessary code signing tools. Several security-related tools will be required. If you have Visual Studio 2005 installed, these are already available (and added to the PATH of a Visual Studio Command Prompt).

Otherwise, download and install the Platform SDK to install the necessary tools (only the Core SDK Tools [32-bit] need to be installed [about 40MB]). The required programs are installed to the Bin path under the Platform SDK install path.

Your digital certificate(s) can be viewed in the Windows certificate store using the Certificate Manager (certmgr.exe), which can also be launched from Internet Explorer (Tools | Internet Options | Content | Certificates for IE 6) or Outlook Express (Tools | Options | Security | Digital IDs for OE 6). The Certificate Manager is also used to import and export certificates.

2. Obtain a Code Signing Certificate

The next step is to get a code signing certificate (or digital ID) from a certification authority (CA) such as Comodo, Thawte, VeriSign, and others. You will need a Class 3 digital certificate for code signing.

During the sign-up process, a private key will be generated; make sure to mark the key as exportable. During this process, you will need to provide an email address, password, and challenge phrase, as well as additional information about your company. Save the private key to a local .pvk file and store it and the information associated with it in a secure location. Once your company information has been verified, the CA will issue the public portion of your digital certificate; you should save this to a local .cer or .spc file during the installation process and also store in a safe place.

Note: You can also create test certificates using makecert.exe.

3. Convert the Certificate File Format

After receiving your code signing certificate, you may need to convert it into a software publishing certficate (.spc) using cert2spc.exe. From a DOS/Command Prompt, run:

cert2spc xyz.cer xyz.spc

Then you should convert your certificate (the public [.spc] and private [.pvk] portions) into a single Personal Information Exchange (.pfx or PKCS #12) file. This simplifies later steps and avoids incompability problems when using the certificate on different versions of Windows:

pvk2pfx -pvk xyz.pvk -pi pvkpassword -spc xyz.spc
-pfx pfxfilename -po pfxpassword -f

Store the .pfx file and the associated password in a secure location.

Finally, import your certificate into a certificate store on the build box by running certmgr.exe, clicking Import, entering the .pfx filename, the .pfx file password, and leaving ‘Enable strong private key protection’ unchecked.

The Easy, Automated Part

The last part, actually signing your executables, is the step that can be added to your automated build process (you are doing automated builds, right?).

During a build, each executable that needs to be signed (you should always sign the installation file and you may also want to sign all application EXEs, DLLs, OCXs that comprise it) can be signed using signtool.exe (line breaks added for easier reading):

signtool sign /a
/t <URL of your CA's timestamp server>
file_to_sign.exe

If you’re using Visual Build Pro, you can use the built-in Sign Code action instead to automate this step. A digital certificate adds about 5K to an executable’s size.

Verify The Digital Signature

After signing an executable, you can verify that the signature is valid and has been applied properly by starting Windows Explorer, browsing to the file and right-clicking on the executable. If the executable has been signed, there will be a Digital Signatures tab on the properties dialog. Switch to that tab, click on the signature, and click Details.

If everything worked, it will show ‘This digital signature is OK’ at the top, and below that the signer’s name, signing time, and information on the digital certificate of the counter-signer. If it instead indicates that the digital signature could not be verified, you need to install a certificate for the code signing Intermediate Authority (the information in the previous link is specific to VeriSign and may not apply for other CAs) on the build box.

You can also automate verification of digital signatures using the Sign Code action or signtool.exe.

Share and Enjoy:These icons link to social bookmarking sites where readers can share and discover new web pages.
  • BlinkList
  • blogmarks
  • del.icio.us
  • digg
  • feedmelinks
  • Furl
  • LinkaGoGo
  • NewsVine
  • Reddit
  • Simpy
  • Spurl
  • YahooMyWeb

23 Comments on “Automating Code Signing of Windows Executables”

  1. Grohol Says:

    Thank you for this tutorial. It’s excellent.

    However, I have a problem with the idea of signing. It’s extortion from Microsoft – they just want our money.

    :-(

  2. kyle Says:

    Microsoft doesn’t provide code signing certificate services, so they don’t make money from that.

  3. norm Says:

    Kinook,
    Thanks for the help, because I just purchased a GeoTrust Cert.
    I was surprised that the code signing is a new product for GeoTrust and they don’t know how it works in Visual Studio 2005. I found and used your help by searching and reading very much hoopla about CA’s value and easy to use stuff. All this reading was of little help. MSDN on this subject is just a little too “startSomewhere-goto-nowI’mBackAt-startSomewhere.” You must know the feeling. It’s “I’ve seen this page before and before.”
    This morning I also opened a Support Incidence with my MSDN subscription. I’m ClickOnce publishing now with the GeoTrust Cert so you just saved me one Support Incidence. That’s worth a lot.
    Thanks again,
    Norm

  4. Craig Says:

    Kinook,

    Thanks for all the information. We have signed .DOT and .POT files that we distribute to our clients which are used by app to create Word and PowerPoint reports. The problem we have encountered is that until the .DOT or .POT file is opened on a client machine at a customer site, Word and or PowerPoint throws an exception. At this time I usually get a phone call from the customer and I have to instruct them to open a DOT file and accept the certificate. After they perform this operation everything works fine.

    I’ve been struggling on how to fix this problem and then I found your article. If I sign our MSI file with the same certificate, they will get the digital security warning and the certificate will be installed on there computer. My question then is what happens if the customer pushes the MSI to the client machine using SMS or something equivalent which some due. Is there a mechanism built into such programs to handle digital certificates? I have no experience with this type of technology and was hoping to get some information from you or someone who might read this post.

    Thanks again for a great article.
    Craig

  5. Rasmus Møller Selsmark Says:

    Thank you for this great article.

    It seems that you don’t have to import/install the certificate on the build machine, but can use the /f argument for signtool.exe:

    signtool sign /v /t http://timestamp.verisign.com/scripts/timstamp.dll /f “(path to .pfx file)” /p (password) TheFile.dll

    This makes it even easier to automate the build process.

  6. kyle Says:

    That’s another option. But then you have to store the PFX password in the build script.

  7. kio Says:

    I dislike the fact that you must sign, in order to seem more user-trustworthy. Profits…

    One person may not be able to sign his/her program/game, yes I am talking about Indie Developers.

    Even if the .exe is unsigned the users will just ignore it. Even Microsoft forgets to sign their own small applications sometimes. So they also see this method is dumb. One mere warning is nice, the security depends on the actions of the user most of the time.

    Microsoft’s security causes more problems than good.

    The application I want to download has no sign so I won’t download it because I won’t trust it.
    I can’t play a multiplayer game because of my firewall settings.
    My antivirus detects an indie-made game as a virus so I must delete the game or uninstall the antivirus.

    Also Symantec provides us with antiviruses and viruses as well, just to terrorize us and make us spend money on their useless antivirus. Remember the w32Blaster virus? Almost anyone got that virus and we had no protection, and rumors say that Microsoft developed it in order to check the validity of your Windows.

    It’s all Marketing and Profit…

  8. Carl Gundel Says:

    I must agree with Kio. Someone is making money here, and having a signed EXE means absolutely nothing about the quality and trustworthyness of an application.

    On the other hand, it seems like small developers will lose sales if their apps are not signed. So with that in mind, thanks for the instructional article. :-)

  9. Ian Says:

    I have a question about code signing and the lifetime of the digital ID.

    What happens to a signed executable when the lifetime for the digital ID runs out? Does the code no longer state that it is produced by the group that originally signed it?

    From what I’ve seen, the maximum lifetime you can set is 3 years – at the end of this period you can renew the ID, but does that mean you have to resign your application? If so, how does this work for applications which are on media, where the media is > 3 years old?

    All of this makes me whince – and I tend to agree with the ‘license to print money’ thoughts of others – but it doesn’t detract from the fact that I need to do this.

  10. Fuzzybunny Says:

    Ok please, enough with the conspiracy theories.

    The purposes of signing (as indicated in the article) are:

    #1. Verify the identity of the creator of a document
    #2. Know that the document has not been altered since it was signed
    #3. Verify when it was signed.

    Not mentioned was the ability to revoke certificates.

    This is about trust, nothing more and nothing less. Look at regulations like ISO 9001 and other “certifications” businesses need…those are in place to develop a standard method of operating a business and to provide a reliable source of goods/materials/services. Yes, people have turned it into a profit factory…but paying $10,000 for an ISO 9001 audit, or salaries of ISO Professionals to get you into compliance (which sometimes takes years) is much greater than the amount of money you’re going to shell out for a certificate. Manufacturers that bear the ISO 9001 certification are “trusted” to be a good business that have standards and comply with the requirements of the cert.

    So what’s the difference when we apply that to software. Well, since webservers are soooooo easy to pwn nowadays, signing is a good idea because that verifies to the person that downloaded the software Company XYZ made this software, and the cert from Verisign has not been revoked, and its been digitally signed therefore it has not been tampered with and I can install it *if* I trust both the companies.

    It would be easy to think that the big evil Microsoft Corporation did this to make a profit, but certificates have been around for years. The reason we have signing and XP SP2 have red-flags for all .exe’s and signed/unsigned applications is because of computer-inepts that install nasty little applications accidentally etc. You should see Vista! Its even worse!

    There is nothing wrong with a company delivering a product to make a profit. Certificates were not made to increase Microsoft Profits, and I’m pretty sure they don’t get “kickbacks” from trusted roots, despite whatever you “theorists” have concluded. Do you get mad at the profits your company makes that employs you? Obviously not, because then you wouldn’t have a job.

    Yes some of Microsoft’s trade/business practices aren’t the most ethical and are quite bullyish, but they get away with what they can and pay the price later. Those “bullyish” practices have made them what they are today, and I commend them for it. Its about darwinism here…they have a superior product and therefore dominate/adapt/survive in the marketplace. If MS does something illegal, someone sues them and all is forgiven.

    Keep in mind MS has to develop a user friendly OS that is Secure to maintain and adapt to its environment. You’ll see Vista is an example of this. By using certificates we can enhance security and even use them for encryption. Also, noone has mentioned yet that a Microsoft Server has Certificate Services included with the OS, so you really don’t have to pay Verisign or Thawte etc…you could deploy a CA on your own! Only thing is, you need to know/estimate how much your users will trust you providing the software AND the certificate, as well as your revocation policies.

    When you verify your identity to Thawte or Verisign, others are familiar with the means they use to ensure you are who you say you are…so therefore it makes it nearly impossible to obtain a certificate for something you are not. This is what people respect and the foundation of Certificate Services.

    So if MS includes this in their Server Operating sytem, and you can make certificates using XP Pro (but can’t manage a PKI), then please tell me how the conspiracy theory unfolds? Ignorance is the basis and starting point of prejudice, racism and hatred.

    -Bunny

  11. kyle Says:

    Ian: As long as the certificate was timestamped, it will continue to be valid even after the certificate has expired.

  12. Ravi Keecheril Says:

    Options for Indie developers:

    Code signing certificates are getting cheaper. For example comodo provides certificates for $85 USD. CACert gives free certificates, although their public keys do not come preinstalled with windows, so the coverage is not so good. I hope that changes in Vista.

    And for Indie developers, Thawte Web Of Trust is free. All you need to do is meet another Web of Trust verified member in your area, face to face, with a valid ID…. And Thawte is owned by Verisign, so the coverage is as good.

  13. mattias Says:

    Timestamping is very important, so do not forget the -t above, or the program will stop working with the certificate expires.

    However, if you sign from within Office, you need to edit the registry.

    http://search.thawte.com/thawte/solution.jsp?id=vs9288

    I was bit by this and had to make a re-release of an old program just because I forgot to timestamp from within Office

  14. Sigivald Says:

    To save someone else ages of heartache I just suffered through, it is VITALLY IMPORTANT when doing pvk2pfx, to specify all three parameters (source, password, and output).

    If you see the signature wizard GUI at any point in the process, it WILL create a corrupt .sst file, and you won’t be able to sign anything with it successfully.

    (“No provider was specified for the store or object.”, after misleadingly assuring you it’s using your certificate.)

    Ask me how I know.

  15. Bart Says:

    Well, the article looks good (it gave me the right insight of code signing), but all in all it is just a lot of work for nothing. We develop programs for only one customer and this code signing thing is just annoying. Of course the clietn trusts us. We put it on their computer, we write the software for them; we in fact have *contracts* with the clients. The machines aren’t connected to the net. And still Windows wants the software to be signed.

    For us, it is just a nag screen with no additional value.

  16. Germán Says:

    Thank you for the article. It is very comprehensive. Still i am having the suspicious hat today:
    It is not that our developers are not of confidence, but if you have a development team, each developer running their own building process , is there a security risk in just giving the certificate to all of them and getting that included in their building processes? You know, staff rotation is inevitable.
    Any thoughts on this?

  17. kyle Says:

    When installing a certificate into the store, you can mark it non-exportable so that it can only be used on that machine and not by former employees on another computer.

  18. Germán Says:

    To have a machine devoted to certification entails that each developer after building a new exec needs to go to that machine locate the executable, sign it an take it back.

    We opted to have the certificate and tools in a network drive. Just created a small console program to make it easy to sign: just invoke that program with the filename of the exec as an argument.
    It´s not perfect but at least hides the password of the certificate and makes signing easier to automate in the building process from the developer box.

  19. Dan Says:

    Thanks again for the great article. It’s the most concise explanation of code signing I’ve seen so far, and I’ve been searching for a while.

    I have a handful of build boxes, and I’d like them all to have access to my certificate. I’d prefer to store my certificate onto a ‘certificate server’ and have the code signing process on each box reference that central location over the LAN. Does anyone know if that is possible, or if I’ll need to import the certificate into each build box?

  20. kyle Says:

    It appears that it’s possible to configure a global enterprise store and have each computer download from there automatically.

  21. Stefan Bookholt Says:

    Hello,

    Great article. I missed some minor steps to get this working on a test environment. Those steps are:
    - Makecert requires an option to export the private key, use -sv [privatekeyfilename]
    - Signtool has a GUI to sign a file. use singtool signwizard to launch the gui.

  22. Spades Oliver Says:

    Hi,
    In my company, we sign each file online (via signtool.exe )
    I have 2 questions for you:
    1. If i use a certification of a firm (verisign) and i want to use another one, may i have to change any code on the website?
    2. If i use another firm, may the key less secured or not work properly?
    ( i ask it because, in some company you pay $500 for a key and in another $100. So i don’t know why there is the difference between 2 company?)
    thank you for your help

  23. kyle Says:

    1. No, just re-sign the file with the new certificate and upload.

    2. I think they’re all more-or-less equivalent as long as Windows has the root CA certificate for the vendor (I believe XP does for all the major vendors).

Comment: