CryptographicException 'conjunto de chaves não existe', mas apenas através de WCF

StackOverflow https://stackoverflow.com/questions/602345

  •  03-07-2019
  •  | 
  •  

Pergunta

Eu tenho algum código que faz uma chamada para um serviço web de terceiros que seja protegido usando certificação X.509.

Se eu chamar o código diretamente (usando um teste de unidade) funciona sem problemas.

Quando implantado, este código será chamado através de um serviço WCF. Eu adicionei um teste de segunda unidade que chama o serviço WCF, porém esta falha com um CryptographicException, "Keyset does not exist" mensagem quando eu chamar um método no serviço de terceiros web.

Eu presumo que isso é porque o meu serviço WCF será tentar chamar o serviço web de terceiros usando um usuário diferente para mim.

Alguém pode lançar alguma luz sobre esta questão?

Foi útil?

Solução

Ele provavelmente será um problema de permissões no certificado.

Ao executar um teste de unidade que você vai estar executando aqueles sob seu próprio contexto de usuário, que (dependendo do que armazenar o cliente certificado está em) terá acesso à chave privada desse certificado.

No entanto, se o serviço WCF está hospedado no IIS, ou como um serviço do Windows é provável que ele será executado sob uma conta de serviço (serviço de rede, serviço local ou alguma outra conta vinculada).

Você precisará configurar as permissões apropriadas na chave privada para permitir que o acesso da conta de serviço para ele. MSDN tem os detalhes

Outras dicas

Isso é mais provável porque o usuário IIS não tem acesso à chave privada para o seu certificado. Você pode definir isso seguindo estes passos ...

  1. Iniciar -> Executar -> MMC
  2. Arquivo -> Adicionar / Remover snap-in
  3. Adicione o Certificados Snap In
  4. selecione Conta de computador, em seguida, bateu próximo
  5. selecione Computador local (o padrão) e clique em Concluir
  6. No painel esquerdo da Raiz do console, para navegar Certificados (computador local) -> Pessoal -> Certificados
  7. O certificado será provavelmente mais aqui.
  8. clique com o botão direito no seu certificado -> Todas as tarefas -> Gerir Chaves Privadas
  9. Defina suas configurações de chave privada aqui.

Eu tive problema idêntico na noite passada. As permissões em chave privada foram definidas corretamente, tudo estava aparentemente bem, exceto o conjunto de chaves não existe erro. No final, descobriu-se que o certificado foi importado para o armazenamento do usuário atual em primeiro lugar e, em seguida, mudou-se para armazenamento do computador local. No entanto - que não se moveu a chave privada, que ainda estava no

C: \ Documents and settngs \ Administrator ...

em vez de

C: \ Documents and settngs \ Todos os usuários ...

Altough permissões na chave foram definidos corretamente, ASPNET não poderia acessá-lo. certificado quando nós re-importado para que a chave privada é colocado no All usuários ramo, o problema desapareceu.

Para resolver o “O conjunto de chaves não existe” quando se navega a partir do IIS: Pode ser para a permissão privada

Para ver e dar a permissão:

  1. Executar> mmc> sim
  2. clique no arquivo
  3. Clique em Adicionar / Remover Snap-in ...
  4. Clique duas vezes no certificado
  5. Conta de computador
  6. Seguinte
  7. Concluir
  8. Ok
  9. Clique em Certificados (Computador Local)
  10. Clique na pessoais
  11. Clique em Certificados

Para dar a permissão:

  1. clique direito sobre o nome do certificado
  2. Todas as tarefas> gerenciar chaves privadas ...
  3. Adicionar e dar o privilégio (adicionando IIS_IUSRS e dando-lhe as obras de privilégio para mim)

teve o mesmo problema ao tentar executar o aplicativo WCF a partir do Visual Studio. Resolveu por executando o Visual Studio como administrador.

Já enfrentei este problema, meus certificados onde ter a chave privada, mas eu estava recebendo este erro ( "O conjunto de chaves não existe" )

Causa:. Seu site está sendo executado em "Serviços de rede" conta ou ter menos privilégios

Solução : Alterar Aplicativo piscina identidade para "Sistema Local", redefinir o IIS e verifique novamente. Se ele começa a trabalhar é problema de permissão / Menos privilégio, você pode personificar em seguida, usando outras contas também.

totalmente frustrante, eu tive o mesmo problema e tentou a maioria dos acima. O certificado exportado teve corretamente permissões para ler o arquivo em C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys, no entanto, como se vê que não tem permissão na pasta. Adicionado e funcionou

Eu tenho problema exatamente semelhante também. Eu tenho usado o comando 

findprivatekey root localmachine -n "CN="CertName"

o resultado mostra que a chave privada é na pasta c: \ ProgramData em vez de C: \ Documents and settngs \ Todos os usuários ..

Quando eu excluir a chave da pasta c: \ ProgramData, novamente executar o comando findPrivatekey não terá êxito. ie. não encontrar a chave.

Mas se eu procurar a mesma chave devolvido pelo comando anterior, eu ainda pode encontrar a chave na

C: \ Documents and settngs \ Todos os usuários ..

Assim, para o meu entendimento, o IIS ou o WCF hospedado não é encontrar a chave privada a partir de C: \ Documents and settngs \ Todos os usuários ..

Eu estava recebendo o erro: CryptographicException 'conjunto de chaves não existe' quando eu executar o aplicativo MVC.

solução foi: dar acesso aos certificados pessoais para a conta que pool de aplicativos é executado. No meu caso, foi adicionar IIS_IUSRS e escolher o local certo resolvida esta questão. 

RC on the Certificate - > All tasks -> Manage Private Keys -> Add->  
For the From this location : Click on Locations and make sure to select the Server name. 
In the Enter the object names to select : IIS_IUSRS and click ok.

Eu encontrei algumas informações em falta que me ajudou a conseguir o meu serviço WCF com mensagem de segurança de nível após o "O conjunto de chaves não existe" que eu ficava correndo para apesar de conceder permissões a todas as chaves geradas a partir dos exemplos na internet.

Eu finalmente importado a chave privada para as pessoas de confiança armazenar no computador local e, em seguida, concedeu a chave privada as permissões corretas.

Esta preenchido os espaços em branco para mim e, finalmente, permitiu-me para implementar o serviço WCF com segurança em nível de mensagem. Eu estou construindo um WCF que deve ser compatível com HIPPA.

Se você usar ApplicationPoolIdentity para o seu pool de aplicativos, você pode ter problema com especificando a permissão para que o usuário "virtual" no editor de registro (não existe tal usuário no sistema).

Assim, o uso subinacl - ferramenta de linha de comando que permite set registro ACL, ou algo assim.

Eu só queria acrescentar uma resposta verificação de sanidade. Eu estava recebendo exatamente o mesmo erro mesmo depois de instalar os certificados para as lojas certas em minhas máquinas e ter todos os privilégios de segurança adequadas para o cliente. Acontece que eu misturei meu ClientCertificate e meu Certificado de Serviço. Se você já tentou todas as opções acima, gostaria de verificar que você tem aqueles dois em linha reta. Uma vez eu fiz isso, meu aplicativo chamado com sucesso o serviço web. Novamente, apenas um verificador de sanidade.

Recebeu esse erro ao usar o Fedlet OpenAM no IIS7

Alterar a conta de usuário para o site padrão resolveu o problema. Idealmente, você iria querer que este seja uma conta de serviço. Talvez até mesmo a conta IUSR. Sugerir olhando para cima métodos para endurecimento IIS para pregá-la completamente.

Eu bati esta no meu projeto tecido serviço após a cert usado para autenticar contra o nosso cofre key expirou e foi girada, que mudou a impressão digital. Eu tenho esse erro, porque eu tinha perdido atualizar a impressão digital no arquivo applicationManifest.xml neste bloco que faz precisamente o que as outras respostas sugeriram - para determinada rede serviço (que todos os meus exes executado como, configuração padrão para Azure conjunto servicefabric) permissões para acessar o local LocalMachine \ MY cert loja.

Observe o "X509FindValue" valor do atributo. 

<!-- this block added to allow low priv processes (such as service fabric processes) that run as NETWORK SERVICE to read certificates from the store -->
  <Principals>
    <Users>
      <User Name="NetworkService" AccountType="NetworkService" />
    </Users>
  </Principals>
  <Policies>
    <SecurityAccessPolicies>
      <SecurityAccessPolicy ResourceRef="AzureKeyvaultClientCertificate" PrincipalRef="NetworkService" GrantRights="Full" ResourceType="Certificate" />
    </SecurityAccessPolicies>
  </Policies>
  <Certificates>
    <SecretsCertificate X509FindValue="[[THIS KEY ALSO NEEDS TO BE UPDATED]]" Name="AzureKeyvaultClientCertificate" />
  </Certificates>
  <!-- end block -->

Eu só reinstalado meu certificado na máquina local e bem, então ele está trabalhando

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top