Ramblings from a software developer


Something that has bothered me for a while is the hassle in putting together all the pieces to sign my download files. I finally got around to looking it all up, and it isn’t easy as you have to piece all the things together. I hope that this will give you an insight into how it can really work, since I managed to actually achieve what I wanted and sign my code. This article is a list of the steps I had to take, and you will probably need to review the commands yourself if you have problems.

Update 2006:

How things change. Since I wrote this original article, things in the codesigning world have become a lot easier. I’ve even renewed the two year certificate I bought – but watch out that you get the renewal from the expiry of the first one or you could lose many days!

The main change though is that Microsoft made the signcode executable very hard to find, if not impossible. The good news is that there is a much better option available and, although it isn’t free, it is more comprehensive and offers a GUI mode for your initial testing and a command line option (signcode compatible) for your development script. The best improvement is that you can specify the password for the certificate, which means you don’t have to have the password dialog pop up all the time. Full details, and links to certificate suppliers and a step-by-step guide are available from the X2Net SignCode web page.

I’ve left the original article below as it is still a good summary of the tools that might be useful to people, and how to transform things.

The process

Get a certificate from http://www.ascertia.com/onlineCA/Issuer/CerIssue.aspx who will do a free code signing certificate. Obviously any alternative is good, but this will prove the concept for you, and you can go buy another from them or elsewhere later. The email address is included in the certificate, so use a sensible one you are happy for the world to see. Accept the installation of the certificate into the browser as it won’t be emailed even though they say it will. Make sure you chose exportable.

Then get the Microsoft code signing stuff (codesigningx86.exe) from the MSDN web site (google will find its current location).

Use the certmgr to view your certificate and export it. Export it as a certificate (.cer file), and with the key (.pvk) file.

Use cert2spc to convert the cer file into an spc file. That’s the first half of the process done. Now you need a key file compatible with the signcode application.

From http://support.globalsign.net/en/objectsign/transform.cfm:

How to transform your certificate to a pvk + spc combination.

Export your certificate to a pfx file (be sure to check “Include all certificates in the certification path if possible”). (The latter will help ensure it is accepted by more systems.

Install openssl. You can find compiled binaries on www.openssl.org (but get the Windows build from http://www.shininglightpro.com/ http://www.shininglightpro.com/download/Win32OpenSSL-v0.9.7d.exe)

Extract your private key from the pfx file.

->openssl pkcs12 -in <pfx-file> -nocerts -nodes -out <pem-key-file>

The pfx password will be asked.

Download the pvk transform utility. This file can be found at http://support.globalsign.net/en/objectsign/PVK.zip.

-> pvk -in <pem-key-file> -topvk -out <pvk-file>

Extract your certificates from the pfx file.

openssl pkcs12 -in <pfx-file> -nokeys -out <pem-certs-file>

The pfx password will be asked.

Transform your pem file to a spc file

->openssl crl2pkcs7 -nocrl -certfile <pem-certs-file> -outform DER -out <spc-file>

I didn’t do that last bit – already did that stage. Note that you are transforming into a PEM file as an intermediate step. I got that bit wrong first time round.

Okay, so now you have all the right bits. You now can just run signcode.exe and use the wizard to check it all works. Select the advanced mode so you can use files, and all should go well. You’ll have to enter the password at various points. If it all worked, then we are nearly there.

To actually sign the code, and I used FinalBuilder to make sure it is done each time and every time reliably, you need the following command.

c:\codesigning\signcode -spc “c:\codesigning\myAscertiaSPC.spc” -v “c:\codesigning\myascertiakey.pvk” -a md5 -i “www.yourdomain.com” -n “Application install file” “C:\Build\Installer\yourinstaller.exe”

If it fails, then you probably got a path wrong or a missing file or something silly. Took me ages to spot that I’d got an extra letter in a path. Grr.

The only fly in the ointment is that you need to type the password for each file. It’s not hard to write an app to do the typing for you, but the security of your password is obviously at risk.

An update: Thanks to Hugo Logmans who also provided the script additions to allow FinalBuilder to check that it worked okay, which ensures that you don’t think you signed it.

CodeSignFailure = true

ActionResult = NOT CodeSignFailure
Continue = NOT CodeSignFailure

if InStr(StatusMessage.MessageText,”Succeeded”) > 0 then
CodeSignFailure = false
end if

I have this script to sign the program executable AND singlefile
installer-executables. Works very fast and efficient. This way you can be sure the file is always signed.

Update: After some issues that someone identified with the ascertia certificate on their machine (which I couldn’t replicate), I bought a two year certificate from http://www.instantssl.com/code-signing/ which is from a fairly new certificate authority, but is cheap therefore and is in the XP SP2 root certificates and thus answers the issues.

Update: The codesign executable is a moving target, and is becoming harder to find. So forget the Microsoft codesign executable, and use one that is much easier to use and not only command line compatible but more comprehensive. Give X2Net SignCode a whirl – both GUI and command line options available.

Matthew Jones