1

I'd like to experiment with signing a software executable. I am afraid that there is something that escapes me.

I will get to the point where I will acquire a certificate from a CA, but before then I would like to know what I am doing, so I did a test:

I created a self-signed certificate:

makecert -r -ss myPrivateCert -sk c:\test -n "CN=My Company Inc." testCert.cer

then signed an executable:

signtool sign /v /s myPrivateCert /n "My Company Inc." /t http://timestamp.verisign.com/scripts/timstamp.dll c:\folder\my_installer.exe

For both commands, I got success.

Step 3: "Install the Test Certificate": http://msdn.microsoft.com/en-us/library/bb756995

Success.

(Note: in the folder c:\test, I placed certificates downloaded from Microsoft's suggested cross-certificate list, like VeriSign Class 3 Public Primary Certification Authority - G5.cer - I'm just guessing that I was supposed to do that.)

I run certmgr c:\folder\my_installer.exe

and I got a list of 3 certificates I had added, with Subject, Issuer, , Serial Number... (from My Company Inc. and Verisign), so apparently everything is good.

Even after that, if I double click the installer (or the executable), I get the UAC message about Unknown publisher...

So what else do I need to do to have that box either disappear or say "My Company Inc." for producer ? And that is only for the local machine, doing everything by hand...

For testing for real, I am assuming that my client is a VirtualBox environment... so ? The next step: move the installer in a VirtualBox and run it ?

But how do I tell the client about the key or certificate or whatever ? Do I copy the cer file along with the exe ? Do I have to put it in a special place ? Do I copy any other files ? Do I have to run mmc again ? Will users have to do something like that ? Because it seems exceedingly complicated, from a user perspective... This is very confusing...

I am assuming that, if I purchase a real certificate from Verisign for example, it would authenticate over the web and I would not have to do anything else (except the two commands above, minus the -r) ?

I have found lots of directions about this on the web, but each left me as confused as when I started - perhaps they each had assumptions of some prior knowledge...

1 Answer 1

2

It doesn't "authenticate over the web" (other than, perhaps, checking the Certificate Revocation List (CRL)) -- the root CAs are hard-wired into the operating system and installed either by Windows Update or by the OS install disk. In other words they are a set of static data on the hard drive that is not (easily) modifiable.

The way you get the annoying box to go away is to either:

  • Trust your snakeoil signing CA (generally a bad idea, but it'll work); or
  • Get it signed by a publicly-trusted official root CA or one of their intermediates.

You cited Verisign. Good. They are one of several possible providers for giving you a code-signing certificate. The box is still appearing because, AFAIK, Windows is programmed to automatically pop up the warning for all self-signed certs. If you were to try and generate a CSR based on your own created root CA, you could get the box to disappear by trusting your root CA, and that would work. But then you'd have to get your clients to trust your root CA, which defeats the purpose in most situations. Hence the public trust network is the easiest path. The vendor usually even gives you explicit instructions on how to use their service and how to sign your code.

7
  • So... if I get a Verisign certificate, what will I have to change in my process ? I would like to have something I can test...
    – Thalia
    Aug 17, 2012 at 20:12
  • That depends on your vendor. makecert is for creating a self-signed certificate. The root CA who gives you your codesigning certificate determines what the process is. Check out for example symantec.com/verisign/code-signing/microsoft-authenticode Aug 17, 2012 at 20:20
  • 1
    For a testable local solution you could use OpenSSL to generate the appropriate root CA, trust it, create a certificate signing request, then generate a certificate, then trust that, then use signtool similarly to how you use it now. Your use of signtool will only change slightly, but your process prior to running signtool will change dramatically from vendor to vendor and depending on whether you're using a self-signed, self-generated root CA, or official public root CA. Aug 17, 2012 at 20:22
  • Thank you. I found this for Verisign... It just wasn't something that I could use: knowledge.verisign.com/support/code-signing-support/…, since I don't know how to get pfx or pvk or spc files. I suppose these files are provided by the CA then...
    – Thalia
    Aug 17, 2012 at 20:30
  • Verisign has a "wizard" that asks you for some information about yourself/your company; then (usually) verifies it somehow; then asks for payment; then it walks you through the process. If you get stuck, you can always get support from them if you're paying them to create a certificate... Aug 17, 2012 at 20:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .