How to give a user access to the Certificate Store on Windows Server 2012?

4

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.

windows-server-2012
certificate
user-permissions
winrm
asked on Server Fault Mar 5, 2015 by simich • edited Mar 5, 2015 by simich

3 Answers

2

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.

answered on Server Fault Mar 12, 2015 by simich
1

Ran into a similar issue with signtool.exe returning "Error: Store::ImportCertObject() failed." (-2146893808/0x80090010). In my case, I was connecting from Linux via ssh and sshd was hosted in a Cygwin environment shell.

The following post at https://cygwin.com/ml/cygwin/2008-10/msg00588.html. seemed a lot relevant. (see also - https://cygwin.com/ml/cygwin/2007-01/msg00651.html)

Either use password authentication instead of public key authentication when logging in through ssh. Password authentication creates a valid logon session, so you're correctly identified and the problem should go away.

The bottom line, either user password based login or set up the service account with appropriate privileges. Somewhere while using certificate-based authentication, the impersonation of users seems not working as expected.

Though an old post, but hope others might find it helpful.

answered on Server Fault Nov 21, 2017 by Nav Kush • edited Nov 21, 2017 by Nav Kush
0

I had an error which was similar to this, and when I searched for it nothing relevant except this came up, so I just wanted to post my solution in case anybody else comes by here with my problem.

The difference is the error code which is "(-2146893792/0x80090020)" instead of the one in the original post.

The issue turned out to be when I converted from JKS to PFX for the certificate store. I used an older version of Java Keytool to do the conversion which did not warn me that changing the keystore password is different from changing the private key password for the certificate. So I ended up with different passwords and most tools (including SignTool) assumes that the passwords are the same. Doing a new conversion making sure to set both private key and store password to the same thing solved the issue.

answered on Server Fault Oct 31, 2016 by Silwing

User contributions licensed under CC BY-SA 3.0