Uso de certificados emitidos por Windows 2008 R2 desde .NET Framework

Si tienen la suerte de tener que utilizar certificados con un template v3 desde Windows Vista o superior, y los mismos fueron emitidos por un Windows Server 2008 R2, se encontrarán con una feliz excepción (Invalid provider type specified.) al intentar obtener la propiedad PrivateKey de una instancia de X509Certificate.

Esto ocurre, como bien se explica en este post debido a que la forma en que Windows Vista y Seven almacenan este tipo de certificado - utilizando Microsoft Software Key Storage Provider - solamente está soportado por CryptoAPI, pero no por las librerías provistas por .NET Framework 4.0 o anterior.

La forma de solucionar esto es utilizando las librerías provistas por los amigos del equipo de CLR Security:

• Incluir "using Security.Cryptography.X509Certificates;" en el archivo que utilizará los certificados para traer los extension methods para la clase X509Certificate2
  
• Preguntar por HasCngKey() en la instancia de X509Certificate2 para saber si la clave esta almacenada de esta forma. En caso afirmativo, crear una nueva instancia de RSACng utilizando el método GetCngPrivateKey() como parámetro.
  

Hasta la próxima!

Zaiden

Interoperabilidad de WebServices con certificados entre .NET con WSE y Java

Pese a que el "espíritu" del standard de WebServices, WS-Security, y demas yerbas planteadas en las RFC supondrían una facilidad para la interoperabilidad ente diferentes plataformas, al intentar llevarlas a la realidad las asperezas surgen... y explotan en nuestra cara.

Hace un tiempo, en Lagash tuvimos que implementar un TokenManager (entre otras cosas) para poder traducir los llamados hechos desde WSE 3 a Java, utilizando certificados de seguridad.

Luego de estar funcionando sin problemas por casi dos años, el servicio comenzó a fallar al momento de recibir la respuesta de un pedido, con un mensaje que decía "WSE590: Failed to resolve the following key info"... y mostraba uno de los nodos de Key Info, conteniendo supuestamente el Subject Key Identifier del certificado necesario para desencriptar el mensaje.

El problema resultó ser que, dado que el nuevo certificado que comenzaron a usar no contenía la extensión de Subject Key Identifier, para poder identificarlo, tanto Java como WSE generaban un hash del certificado. El gran problema gran era que los hashes eran calculados de forma distinta!

Para poder solucionarlo, dentro del input filter de los mensajes hubo que reemplazar la porción de SOAP que indica el certificado a utilizar por una creada a mano que indique el certificado concreto (que, de hecho, siempre es el mismo que se utiliza al enviar el mensaje original).

Para mas información: http://support.microsoft.com/kb/922779/en-us (el problema no es exactamente el mismo, pero el approach para solucionarlo es muy similar).

Saludos!

Zaiden