Estou lutando contra um problema nos últimos dias que não consigo resolver. Eu não sou um administrador, embora eu tenha algum conhecimento sobre algumas tarefas administrativas.
Eu tenho um script do PowerShell que usa o XapSignTool.exe para assinar um pacote .xap. A chave privada e a senha são fornecidas. Quando eu executo o script enquanto estou logado como um usuário no grupo Administradores, ele funciona bem.
Eu também estou executando o serviço de Gerenciamento Remoto do Windows na mesma máquina. De outra máquina Linux, estou usando o protocolo winrm para chamar o script do PowerShell com os parâmetros necessários. Em seguida, a ferramenta XapSignTool.exe, ou especificamente o signtool.exe, usado abaixo, lança um erro:
Error information: "Error: Store::ImportCertObject() failed." (-2146893808/0x80090010)
Procurei o código e descobri o que significa, por exemplo
NTE_PERM
0x80090010
Access denied.
O nome do método ImportCertObject () me faz pensar que a ferramenta tenta importar a chave privada fornecida para o armazenamento de certificados.
O que é interessante é que, se eu executar o script pela primeira vez enquanto estiver conectado e funcionar, as chamadas subseqüentes serão executadas através do trabalho do winrm. Isso me leva a acreditar que o certificado é importado corretamente com um usuário que seja um administrador.
O serviço WRM estava sendo executado na conta do Serviço de Rede, por isso presumi que ele não tem permissões para inserir no Armazenamento de Certificados. Coloquei a conta NS no grupo Administradores com a esperança de que funcionasse, mas isso não aconteceu. Para testes, eu coloquei \ Everyone no grupo Administradores e a chamada winrm para o script do PowerShell ainda falhava com 'Acesso negado'.
Por que isso? Como posso dar acesso ao armazenamento de certificados a um usuário?
Eu também quero ser capaz de fazer isso para muitos desses certificados, por isso tem que ser automatizado.
Após dias de pesquisa, não encontrei o motivo no nível mais baixo de significado, mas um pouco mais alto que o tat.
O script funcionou quando o usuário estava logando como já estava conectado interativamente na máquina. Se eu sair da máquina, o script deixará de funcionar.
Este foi um problema com o WinRM e uma das soluções alternativas foi usar o CredSSP. Outra maneira de resolver esse problema é alterar toda a solução para um serviço HTTP ou um consumidor da fila de mensagens.
Eu tive um erro que era semelhante a isso, e quando eu procurei por ele nada relevante exceto isso, então eu só queria postar minha solução caso alguém viesse aqui com o meu problema.
A diferença é o código de erro que é "(-2146893792 / 0x80090020)" em vez daquele no post original.
O problema acabou sendo quando converti do JKS para o PFX para o armazenamento de certificados. Eu usei uma versão mais antiga do Java Keytool para fazer a conversão, que não me avisou que alterar a senha do keystore é diferente de alterar a senha da chave privada para o certificado. Então acabei com senhas diferentes e a maioria das ferramentas (incluindo SignTool) assume que as senhas são as mesmas. Fazer uma nova conversão certificando-se de definir a chave privada e a senha da loja para a mesma coisa resolveu o problema.
Correu um problema semelhante com o retorno do signtool.exe "Erro: Store :: ImportCertObject () falhou." (-2146893808 / 0x80090010). No meu caso, eu estava conectando do Linux via ssh e o sshd estava hospedado em um shell de ambiente Cygwin.
A postagem a seguir, no link . parecia muito relevante. (veja também - link )
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.
A linha inferior, seja o login com base na senha do usuário ou a conta de serviço com os privilégios apropriados. Em algum lugar durante o uso da autenticação baseada em certificado, a representação dos usuários parece não funcionar como esperado.
Apesar de um post antigo, mas espero que outros possam achar útil.