I've battling an issue for the last couple of days that I cannot seem to resolve. I'm not an administrator although I have some knowledge about some administrative tasks.
I have a PowerShell script that uses XapSignTool.exe to sign a .xap package. The private key and password are provided. When I run the script while logged in as an user in the Administrators group, it works fine.
I'm also running the Windows Remote Management service on the same machine. From another, Linux, machine I'm using the winrm protocol to call the PowerShell script with the required parameters. Then the XapSignTool.exe tool, or specifically the signtool.exe, which is used underneath, throws an error:
Error information: "Error: Store::ImportCertObject() failed." (-2146893808/0x80090010)
I looked for the code and found out what it means, i.e.
NTE_PERM
0x80090010
Access denied.
The ImportCertObject() method's name makes me think the tool tries to import the provided private key to the certificate store.
What's interesting is that if I first run the script while logged in and it works, the subsequent calls through winrm work. This leads me to believe the certificate gets imported properly with a user that is an Administrator.
The WRM service was running under the Network Service account, so I assumed that it doesn't have permissions to insert in the Certificate Store. I put the NS account in the Administrators group with the hope that it would work, but it didn't. For tests I put \Everyone to the Administrators group and the winrm call to the PowerShell script still failed with 'Access Denied'.
Why is this? How can I give access to the Certificate Store to a user?
I also want to be able to do this for many such certificates, so it has to be automated.
Best Answer
After days of researching I haven't found the reason at the lowest meaningful level but slightly higher than tat.
The script worked when the user it was logging in as was already logged in interactively on the machine. If I sign out of the machine, then the script stops working.
This was a problem with WinRM and one of the workarounds was to use CredSSP instead. Another way to resolve this problem is to change the whole solution to an HTTP service or a message queue consumer.