6

I'm signing an EXE program with a certificate issued by a trusted CA. I'm using signtool.exe from the Windows SDK v6.0a.

The certificate is located in the computer store and it is in the "Personals" folder.

My command line is : 

sign /sm /n "My company" /d MyProductName /du http://my.url.com "C:\Setup\setup.exe"

When I run this command on the command line, it works fine. When I run this command in a batch process (called by a webservice, so there is no user logged in when the command is executed), the following error occur :

Number of errors: 1 SignTool Error: ISignedCode::Sign returned error: 0x80092006 No provider was specified for the store or object.

Anybody can help on this ?

Steven Sudit
  • 19,391
  • 1
  • 51
  • 53
Sebastien
  • 570
  • 3
  • 5
  • 18

5 Answers5

3

To save someone time, I had this problem. It turned out my certificate somehow got corrupted. After I removed it from the certificate store and imported it again, the problem went away. I'd suggest creating the PFX file all over or copying it from a location where you know it is not corrupted.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
coder_2007
  • 31
  • 1
2

The problem is that your service process cannot access your private key, which is stored under your account.

Log on into the account that is running the web service and import the private key into a key container. You can do this for example using the strong name tool (sn.exe) of .NET:

sn -i MyCertificate.pfx MyCodeSigningKey

Now, change your build script to use this key container:

signtool sign /sm /a /v /csp "Microsoft Strong Cryptographic Provider" /kc MyCodeSigningKey <other parameters...>

/kc specifies the key container. /kc requires that you specify the "CSP" (Cryptographic Service Provider) via the /csp switch. "Microsoft Strong Cryptographic Provider" is the default provider used by sn.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
oefe
  • 19,298
  • 7
  • 47
  • 66
  • Naive question -- shouldn't the private key be stored in the computer's store, since he's using /sm above? I'm wrestling with the same thing and hoping to avoid putting another tool (sn.exe) on a production machine. – DougN Dec 19 '11 at 17:18
  • The certificate is stored in the machine store, but not the private key. sn is part of the standard .Net installation. – oefe Dec 28 '11 at 15:08
1

I've [just now, just once] experienced the same condition (immediately after a successful invocation with the same parameters except on a different MSI file). Rerunning succeeded on the next execution of the build script. Also using, like you 

/sm /d /du
Not using 
/n
Additionally using 
/t
Ruben Bartelink
  • 59,778
  • 26
  • 187
  • 249
0

I've had this problem as well. Still not quite sure what caused it since I never had the time to find out. The thing I found was that the private key went missing!?

I did what coder_2007 suggests and it worked for one complete automated build but the next one would give the same error. So something on my build server broke the private key after a complete build (including several signed applications).

What I finally ended up doing was, immediately after importing the PFX, to go to %allusersprofile%\Microsoft\Crypto\RSA\MachineKeys and write protect the latest file (the one that match the time of import).

Andreas Magnusson
  • 7,321
  • 3
  • 31
  • 36
0

This can happen if your windows password is changed after the certificate was installed. Changing the password back to what it was will fix it. If you can't do that you'll need to reinstall the certificate.

SilentBlob
  • 1