CryptographicException 'Keyset no existe', pero solo a través de WCF

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

  •  03-07-2019
  •  | 
  •  

Pregunta

Tengo algún código que realiza una llamada a un servicio web de terceros que está protegido mediante la certificación X.509.

Si llamo al código directamente (utilizando una prueba de unidad), funciona sin problemas.

Cuando se implementa, este código se llamará a través de un servicio WCF. He agregado una segunda prueba unitaria que llama al Servicio WCF, sin embargo, esto falla con una CryptographicException , el mensaje " Keyset no existe " cuando llamo a un método en la tercera servicio web de fiesta.

Supongo que esto se debe a que mi Servicio WCF intentará llamar al servicio web de terceros utilizando un usuario diferente para mí.

¿Alguien puede arrojar alguna luz adicional sobre este problema?

¿Fue útil?

Solución

Probablemente será un problema de permisos en el certificado.

Al ejecutar una prueba de unidad, los ejecutará en su propio contexto de usuario, que (dependiendo de la tienda en la que esté el certificado cliente ) tendrá acceso a la clave privada de ese certificado.

Sin embargo, si su servicio WCF está alojado en IIS, o como servicio de Windows, es probable que se ejecute en una cuenta de servicio (Servicio de red, Servicio local o alguna otra cuenta restringida).

Deberá establecer los permisos apropiados en la clave privada para permitir que la cuenta de servicio acceda a ella. MSDN tiene los detalles

Otros consejos

Esto es muy probable porque el usuario de IIS no tiene acceso a la clave privada para su certificado. Puedes configurarlo siguiendo estos pasos ...

  1. Iniciar - > Ejecutar - > MMC
  2. Archivo - > Añadir / Eliminar complemento
  3. Agregar el complemento de certificados
  4. Selecciona una cuenta de computadora, luego presiona siguiente
  5. Seleccione Equipo local (el predeterminado), luego haga clic en Finalizar
  6. En el panel izquierdo de la raíz de la consola, navegue hasta  Certificados (equipo local) - > Personal - > Certificados
  7. Lo más probable es que su certificado esté aquí.
  8. Haz clic derecho en tu certificado - > Todas las tareas - > Administrar claves privadas
  9. Establezca aquí la configuración de su clave privada.

He tenido un problema idéntico anoche. Los permisos en la clave privada se configuraron correctamente, aparentemente todo estaba bien, excepto el error Keyset no existe. Al final resultó que el certificado se importó primero al almacén del usuario actual y luego se trasladó al almacén de máquinas local. Sin embargo, eso no movió la clave privada, que aún estaba en el

C: \ Documents and Setngs \ Administrator ...

en lugar de

C: \ Documents and Setngs \ Todos los usuarios ...

A pesar de que los permisos en la clave se establecieron correctamente, ASPNET no pudo acceder a ella. Cuando reimportamos el certificado para que la clave privada se coloque en la rama Todos los usuarios, el problema desapareció.

Para resolver el & # 8220; Keyset no existe & # 8221; al navegar desde IIS: Puede ser por el permiso privado

Para ver y dar el permiso:

  1. Ejecutar > mmc > sí
  2. haga clic en el archivo
  3. Haga clic en Agregar / quitar complemento & # 8230;
  4. Haga doble clic en el certificado
  5. Cuenta de equipo
  6. Siguiente
  7. Finalizar
  8. ok
  9. Haga clic en Certificados (equipo local)
  10. Haz clic en Personal
  11. Haga clic en Certificados

Para dar el permiso:

  1. Haga clic derecho en el nombre del certificado
  2. Todas las tareas > Administrar claves privadas & # 8230;
  3. Agregue y otorgue el privilegio (agregar IIS_IUSRS y otorgarle el privilegio funciona para mí)

Tuvo el mismo problema al intentar ejecutar la aplicación WCF desde Visual Studio. Se solucionó ejecutando Visual Studio como administrador.

Me he enfrentado a este problema, mis certificados tenían clave privada pero recibía este error ( " Keyset no existe " )

Causa: su sitio web se está ejecutando en " Servicios de red " cuenta o tener menos privilegios.

Solución : cambie la identidad del grupo de aplicaciones a " Sistema local " ;, reinicie IIS y vuelva a verificar. Si comienza a funcionar, es un problema de permisos / privilegios menores, puede suplantar a otras cuentas también.

Totalmente frustrante, tuve el mismo problema y probé la mayoría de los anteriores. El certificado exportado tenía correctamente permisos para leer el archivo en C: \ ProgramData \ Microsoft \ Crypto \ RSA \ MachineKeys , sin embargo, resultó que no tenía permiso en la carpeta. Lo agregué y funcionó

También tengo un problema exactamente similar. He usado el comando 

findprivatekey root localmachine -n "CN="CertName"

el resultado muestra que la clave privada está en la carpeta c: \ ProgramData en lugar de C: \ Documents and Setngs \ Todos los usuarios ..

Cuando elimino la clave de la carpeta c: \ ProgramData, de nuevo, el comando findPrivatekey no se realiza correctamente. es decir. no encuentra la clave.

Pero si busco la misma clave devuelta por un comando anterior, todavía puedo encontrar la clave en

C: \ Documents and settngs \ Todos los usuarios ..

A mi entender, IIS o el WCF alojado no encuentran la clave privada de C: \ Documents and Setngs \ All users ..

Recibí el error: CryptographicException 'Keyset no existe' cuando ejecuto la aplicación MVC.

La solución era: para dar acceso a los certificados personales a la cuenta con la que se está ejecutando el grupo de aplicaciones. En mi caso, fue agregar IIS_IUSRS y elegir la ubicación correcta resolvió este problema. 

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.

Encontré información faltante que me ayudó a obtener mi servicio WCF con seguridad de nivel de mensaje pasado el " Keyset no existe " que seguí corriendo a pesar de otorgar permisos a todas las claves generadas a partir de los ejemplos en Internet.

Finalmente, importé la clave privada al almacén de personas de confianza en la máquina local y luego le concedí a la clave privada los permisos correctos.

Esto llenó los espacios en blanco para mí y finalmente me permitió implementar el servicio WCF con seguridad de nivel de mensaje. Estoy construyendo un WCF que debe ser compatible con HIPPA.

Si usa ApplicationPoolIdentity para su grupo de aplicaciones, puede tener problemas para especificar el permiso para ese " virtual " usuario en el editor de registro (no hay tal usuario en el sistema).

Por lo tanto, use subinacl - herramienta de línea de comandos que habilita el conjunto de ACL del registro, o algo así.

Solo quería añadir una respuesta de comprobación de validez. Estaba recibiendo exactamente el mismo error incluso después de instalar los certificados en los almacenes correctos en mis máquinas y tener todos los privilegios de seguridad adecuados para el cliente. Resulta que mezclé mi certificado de cliente y mi certificado de servicio. Si ha intentado todo lo anterior, me gustaría comprobar que tiene esos dos seguidos. Una vez que hice eso, mi aplicación llamó exitosamente al servicio web. Una vez más, solo un verificador de cordura.

Recibí este error mientras utilizaba el Fedlet de openAM en IIS7

Cambiar la cuenta de usuario para el sitio web predeterminado resolvió el problema. Idealmente, querría que esta fuera una cuenta de servicio. Quizás incluso la cuenta IUSR. Sugiera buscar métodos de endurecimiento de IIS para clavarlo completamente.

Logré esto en mi proyecto de tejido de servicio después de que el certificado utilizado para autenticarse contra nuestra bóveda de claves expirara y se rotara, lo que cambió la huella digital. Recibí este error porque me había perdido la actualización de la huella digital en el archivo applicationManifest.xml en este bloque que hace exactamente lo que otras respuestas han sugerido: al SERVICIO DE RED dado (que todos mis ejecuciones ejecutan como, configuración estándar para el clúster de Azure servicefabric) permisos para Acceda a la ubicación de la tienda LOCALMACHINE \ MY cert.

Tenga en cuenta el " X509FindValue " valor de 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 -->

Acabo de reinstalar mi certificado en la máquina local y luego funciona bien

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top