5

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.

simich
  • 171
  • 1
  • 6

5 Answers5

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.

simich
  • 171
  • 1
  • 6
  • I know this is old, but I got here with exactly the same problem (trying to run signtool through WinRM). It appears the WinRM service runs as a network service. This account has pretty restricted access. There's some more information here: https://msdn.microsoft.com/en-us/library/ff647402.aspx – Peter Dec 16 '16 at 10:03
2

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.

Nav Kush
  • 21
  • 2
  • Seems like an odd combination, but that's exactly what I'm doing as well, with the same results. – Erik Knowles Feb 14 '20 at 22:16
  • For what it's worth, this also happens when SSH-ing from Linux to Window 10.0.17763.1935 using the built-in OpenSSH server (OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5) – philb Apr 21 '22 at 22:39
0

Got this error too while using "signtool.exe": Error information: "Error: Store::ImportCertObject() failed." (-2146893808/0x80090010)

The used pfx file with the certificate was created under windows 10 by converting a java keystore to pkcs12 format with java keytool.exe.

Solution for me: I've created the pfx file under Windows Server 2012 with the same commands used before. Found some rumors on the internet that under windows 10 some default options changed for creating keystores but did not expected that the java keytool is impacted by that...

Fabian
  • 1
0

I came across this same issue. A Jenkins Agent (Windows on-demand EC2) would not allow the use of a PFX file when code signing. whoami within a pipeline job showed user as Windows administrator but I guess Jenkins uses WinRM also (possibly?) which runs as network system. Strangely logging on to the ec2 via RDP allowed the same code to work via the pipeline that was previously giving an error. So yeah, literally log onto the EC2 and re-run the job and it's fine.

My fix was to use import-pfxcertificate to import the PFX to Cert:\LocalMachine\My & Cert:\LocalMachine\Root then I used signtool with the /sm param instead of pointing it directly to the pfx file. I hope this helps someone, this problem wasted a lot of my time.

Chris
  • 1
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.

Silwing
  • 101
  • 2