.net - password - CryptographicException ''Keyset no existe'', pero solo a través de WCF

wcf basic authentication username password

Question

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

Si llamo directamente al código (usando una prueba de unidad), funciona sin ningún problema.

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 CryptographicException , el mensaje "Keyset does not exist" cuando llamo a un método en el servicio web de terceros.

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 tema?

Answer 1

Encontré información faltante que me ayudó a obtener mi servicio WCF con seguridad de nivel de mensajes más allá del "conjunto de claves no existe" que seguí encontrando a pesar de otorgar permisos a todas las claves generadas a partir de los ejemplos en Internet.

Finalmente importé la clave privada en la tienda de personas de confianza en la máquina local y luego otorgé 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 mensajes. Estoy construyendo un WCF que debe ser compatible con HIPPA.

Answer 2

Esto es más probable porque el usuario de IIS no tiene acceso a la clave privada para su certificado. Puede configurar esto siguiendo estos pasos ...

1. Inicio -> Ejecutar -> MMC
2. Archivo -> Agregar / Quitar Snapin
3. Agregue el complemento de certificados
4. Seleccione Computer Account, luego presione next
5. Seleccione la computadora local (la predeterminada), luego haga clic en Finalizar
6. En el panel izquierdo de Console Root, vaya a Certificados (computadora local) -> Personal -> Certificados
7. Su certificado probablemente estará aquí.
8. Haga clic derecho en su certificado -> Todas las tareas -> Administrar claves privadas
9. Establezca la configuración de su clave privada aquí.

Answer 3

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

C: / Documents and settngs / Administrator ...

en lugar de

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

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

Answer 4

Llegué a esto en mi proyecto de tela de servicio después de que el certificado utilizado para autenticar contra nuestra caja fuerte de claves expiró y se rotó, lo que cambió la huella digital. Obtuve 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 me sugirieron, dado el SERVICIO DE RED (que todos mis archivos ejecutan como configuración estándar para clusters de clústeres de servicios de azure) a acceder a la LOCALMACHINE / MY cert store location.

Tenga en cuenta el valor del atributo "X509FindValue".

<!-- 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 -->

Answer 5

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 ejecuta en la cuenta "Servicios de red" o tiene 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 permiso / Menos privilegio, puede suplantar y luego usar otras cuentas también.

Answer 6

Probablemente será un problema de permisos en el certificado.

Al ejecutar una prueba unitaria, usted los ejecutará bajo su propio contexto de usuario, que (dependiendo de en qué tienda se encuentre el certificado del cliente ) tendrá acceso a la clave privada de ese certificado.

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

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

Answer 7

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

La solución fue: dar acceso a los certificados personales a la cuenta en la que se ejecuta el grupo de aplicaciones. En mi caso, fue para 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.

Answer 8

Recibió este error mientras usaba openAM Fedlet en IIS7

Cambiar la cuenta de usuario para el sitio web predeterminado resolvió el problema. Lo ideal es que quieras que esta sea una cuenta de servicio. Tal vez incluso la cuenta IUSR. Sugiera buscar métodos para el endurecimiento de IIS para clavarlo por completo.

Answer 9

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

Por lo tanto, use subinacl - herramienta de línea de comandos que habilite establecer ACL de registro, o algo como esto.

Answer 10

Solo quería agregar una respuesta de verificación de cordura. Obtuve exactamente el mismo error incluso después de instalar los certificados en las tiendas correctas en mis máquinas y tener todos los privilegios de seguridad correctos para el cliente. Resulta que mezclé mi Certificado de cliente y mi Certificado de servicio. Si has probado todo lo anterior, verificaría que tengas esos dos derechos. Una vez que hice eso, mi aplicación llamó con éxito al servicio web. De nuevo, solo un corrector de cordura.

Answer 11

Tengo un problema exactamente similar también. He usado el comando

findprivatekey root localmachine -n "CN="CertName"

el resultado muestra que la clave privada se encuentra en la carpeta c: / ProgramData en lugar de C: / Documents and settngs / All users ..

Cuando elimino la clave de la carpeta c: / ProgramData, nuevamente ejecuto el comando findPrivatekey no funciona. es decir. no encuentra la clave.

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

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

Por lo tanto, a mi entender, IIS o WCF alojado no está encontrando la clave privada de C: / Documents and settngs / All users ..

Answer 12

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

Answer 13

Tuve el mismo problema al intentar ejecutar la aplicación WCF desde Visual Studio. Lo resolvió ejecutando Visual Studio como administrador.

Answer 14

Para resolver el "Conjunto de claves no existe" 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 / eliminar complemento ...
4. Haga doble clic en el certificado
5. Cuenta de computadora
6. Siguiente
7. Terminar
8. De acuerdo
9. Haga clic en Certificados (computadora local)
10. Haga 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 ...
3. Agregue y otorgue el privilegio (agregando IIS_IUSRS y dándole el privilegio que funciona para mí)