How do I use signtool.exe correctly in hudson running as a service?

Question

I just purchased a code signing cert (MS authenticode) from THAWTE and have installed it apparently on my build machine. I am logged in as a user and when I open a cmd prompt I can sign EXEs using the cert with signtool.exe.

Unfortunately this same command line does not work in the hudson process that is running on the machine.

the error message I get is:

SignTool Error: No certificates were found that met all the given criteria.

I presume this is because the hudson service is running under a different account than the account that I ran signtool.exe from and from the account I used to get the cert from thawte.

So, my question is: How do I fix this problem? I thought i was going to download a file from thawte, but instead it just used IE somehow to install the cert in the user's cache magically. I probably want to export (or whatever the correct term is) to a file that I can store/save or use on any other machine.

How do i do that and how do I call signtool correctly with either the file or the cert from another user in the system/services account?

Realtor

Answer 1

Taken from signtool sign -h output:

/s <name>   Specify the Store to open when searching for the cert. The default
is the "MY" Store.
/sm         Open a Machine store instead of a User store.

Getting this to work is a bit of a pain... I was able to get it to work by adding the certificates to the local machine store and using the /sm switch.

The /s switch allows you to select which pre-defined store to use. Unfortunately I can't find any documentation that lists what the available options actually are (@Microsoft signtool maintainer: please document this!). An additional complication is that it is hard to determine which store Hudson provides access to - it isn't the local security hudson account as you might expect.

Note: The "Personal" store listed in mmc views is the "MY" store when accessed from signtool.

Thankfully the /sm switch provides us with a get-out-of-jail-free card. Unfortunately this would be a security risk if your build server runs jobs for multiple organizations or departments. In my case it is only used by my group, so this doesn't bother me.

Glimmer

Answer 2

For reference purposes, I'll add our experiences here. We are using TeamCity to build a signed ClickOnce app. It took me several hours to get this right, so I hope this saves someone else some time.

Note: I'm running this on a Windows 2k3 server which is also a domain server (yeah, I know).

1. We use a Code Signing Certificate from GoDaddy. The CSR was generated with Internet Explorer. So completing the issueing with Internet Explorer, I basically ended up with the Code Signing Certificate installed under my own account.

2. Because I needed the certificate on the build server, I picked in IE:

   [Extra] > [Internet Options] > [Content] > [Certificates]

   Then I right-clicked the certificate and [Export]'ed. I ticked [Export personal key] and chose the PFX format with [Export all certificates] and [Export all properties] on (not sure if that last one is really necessary). Finally, after specifying the location, I had my Precious.

3. Now I was ready for some real pain, but to spare you the details, I'll skip the nasty hickups. As TeamCity was running under the System account, I needed to have this certificate on our build server under that very same account. So on the build server, I invoked:

   C:\> psexec -i -s cmd

4. That threw a command line at me, running as the System user. Now I called my rusty IE again:

   C:\> C:\Program Files (x86)\Internet Explorer\iexplore.exe

5. I navigated my way to the certificates, and instead of exporting, I chose Import and selected the certificate that I earlier exported. I let Windows choose where to store them.

6. Now everything was in place to have ClickOnce use the certificate to sign our app. We just had to make sure that ClickOnce knew about it. I did not want to put our key file in a code repository, so in my local Visual Studio on the [Signing] tab of the Project properties, I ticked [ClickOnce manifests] and used [Select from Store...] instead of [Select from File...]. This allowed me to pick my locally installed certificate. At that very moment, VS created a property <ManifestCertificateThumbprint> which is the single most important thing in getting this to run on the build server.

   Note that I also added a Timestamp server which is not obligated, but strongly advised for signing software. Otherwise, your software might stop validating when your certificate expires. For GoDaddy, the time server is http://tsa.starfieldtech.com.

   Also note that I did not Sign the assembly (yet). Just telling so you know that this is possible.

7. Now the build server would pick up the project file and the fresh ManifestCertificateThumbprint property, and feed it to the SignTool task. In order to get that one running, I had to copy over signtool.exe from C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin to the same location on the build server.

   Serious nasty debugging has gone into figuring out why the signtool was not working. I pulled out tools like ProcMon and Process Explorer to find out which registry keys were being requested by which command lines. I recreated the actual command line invoked by the SignTool, and watched the effects with those tools.

Finally, after a lot of intense development and sysadmin pain, I was able to deploy our signed ClickOnce app. Cheers!

Linkman

Answer 3

This is a bit old now but I just had a similar problem that is worth documenting I thought.

I have a Jenkins CI server running on Win2008R2 as service that couldn't find a the certificate when running a job, but manually I could sign anything on the same machine.

signtool sign /sha1 ### file.dll  
SignTool Error: No certificates were found that met all the given criteria.

The problem was that the Jenkins service was running as Local Machine - so I thought that using the above answer would work.

signtool sign /sm /sha1 ### file.dll

Same error. /a didn't do anything either.

I got it working by creating a user 'Jenkins' as Administrators group member, running the service as the user 'Jenkins', logging in as Jenkins user and installing the certificate in the user store.

Yes, I did install the certificate as to the local machine store. I even confirmed that the service store had the certificate by using mmc and adding the Service Account - Jenkins store.

Treen

Answer 4

I thought this would be a simple issue to resolve. Instead, it is turning into a greek tragedy.

The provider, Thawte, apparently thinks it is useful to require all certificate actions to occur on the same machine and browser that the request was initiated from. Unfortunately in my case I did it from a Windows7 machine. Due to some MS nonsense that means when I obtained the certificate I cannot export it with the private key. That is only possible on Win2000 an XP. So I need to use a 7 year old OS to do something fundamental for my business. This is mind-blowing.

It turns out that now I am waiting for the third request of the certificate to be fulfilled.

Realtor

Answer 5

I had a similar issue when trying to sign an executable via Jenkins slave on windows. Problem was that since jenkins was running as a service on the windows slave, the signing tool failed finding the imported certificate on the Personal Certificate store (which is supposed to be the default store picked by the signing tool according to microsoft Reference)

I was getting the following error from jenkins console:

SignTool Error: No certificates were found that met all the given criteria.

With the following workaround I was able to fix the signing issue on jenkins:

• Remote desktop to your windows slave
• Open windows mmc (Select Run from the Start menu, and then enter mmc)
• Create a new certificate snap-in (File -> Add/Remove Snap-in)
• Select the Certificates snap-in and add it
• Configure the snapin to manage the certificates for Computer Account
• Click OK and then Finish
• Add the new Snap-in by clicking OK
• Now go and expand Trusted Root Certificates Authorities, right-click on Certificats->All Tasks->Import
• Import your signing certificate, follow the instructions and you should be all set

Tolerate