Confiar en una CA no confiable: ¿puedo restringir la forma en que el sistema confía en ella?


32

(Publicado en ServerFault en lugar de StackOverflow porque siento que se refiere a la configuración del sistema operativo más que al código de programación).

Actualmente soy responsable de mantener un sistema que se conecta a un servicio web de terceros. Este servicio web requiere certificados de autenticación del cliente, lo cual es bastante justo, pero el servicio web en sí está asegurado con un certificado autofirmado creado por un certificado de autoridad de certificación raíz creado por uno mismo, la misma raíz que crea los certificados de autenticación del cliente.

Sería suficiente simplemente agregar el certificado de servicio actual a la lista de confianza conocida e ignorar el certificado de autoridad de creación propia, desafortunadamente el certificado de servicio cambia regularmente, por lo que el certificado de autoridad debe ser confiable para garantizar que la aplicación no se rompa cuando el Se renueva el certificado de servicio.

Sin embargo, (personalmente) no confío en el certificado de CA en base a mi experiencia con la compañía que ejecuta el servicio web, no me sorprendería si se filtrara a la web, y preocupantemente el certificado de CA no tiene restricciones de uso de claves impuestas. (aunque los ataques MITM externos son una posibilidad, aunque remota, estoy más preocupado por un certificado filtrado utilizado para la firma de código, por ejemplo).

¿Es posible que le diga a mi computadora (actualmente una caja de servidor, pero en el futuro cajas de clientes de escritorio normales) que confíe en una CA pero solo para un conjunto dado de usos clave y un pequeño conjunto de posibles nombres de sujeto (nombres de dominio )?

El servidor es actualmente Windows Server 2012 R2, pero podría estar ejecutándose en una caja de Linux, aunque las máquinas de escritorio son todas cajas de Windows.


3
Al menos en Linux, muchas aplicaciones tienen una opción para especificar la ubicación de los certificados de CA pares, por lo que puede limitar el alcance de esta CA a solo la aplicación que lo utiliza. La respuesta de @CryptoGuy también funcionaría en Linux, no hay nada específico de Windows en ella.
Edheldil

1
@Edheldil: Sin embargo, es específico de la implementación; por ejemplo, Windows ha admitido restricciones de nombre X.509 durante mucho más tiempo que, por ejemplo, NSS o GnuTLS.
Grawity 05 de

Su sistema se conecta a este servicio de terceros; ¿se puede configurar el código de cliente en su sistema para confiar en la CA de ese servicio, de tal manera que se haga solo para ese código de cliente , no para todo su sistema?
Castaglia

@Castaglia Puedo escribir mi propio código de verificación de certificado que funciona independientemente del sistema host, pero hay otras piezas de software de cliente sobre las que no tengo control y que utilizan servicios de certificados en todo el sistema.
Dai

Respuestas:


40

Sí, es posible. En el caso de Windows, hay una característica llamada Certificación cruzada o Subordinación calificada.

La idea es que firme el certificado de CA emisor de un tercero en su entorno. Como resultado, el certificado SSL remoto se encadena a su propio certificado de CA raíz. Para protegerse de posibles certificados falsos, implementa unName Constraints extensión de certificado donde especifica una lista de nombres aceptables. Si un certificado de emisión de CA de terceros para cualquier otro nombre (no especificado explícitamente en la extensión de Restricciones de nombre), su proveedor de CryptoAPI lo rechazará automáticamente.

Además de las restricciones de nombre, puede describir la restricción de usos de clave mejorados definiendo la Application Policiesextensión del certificado en el certificado cruzado. Por lo tanto, su proveedor de confianza validará con éxito solo los usos especificados en la Application Policiesextensión.

Más información: Planificación e implementación de certificación cruzada y subordinación calificada con Windows Server 2003

ps aunque, el artículo está escrito en contra de Windows Server 2003, el artículo todavía se aplica a la versión más reciente de Windows Server.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.