Pregunta ¿Es posible confiar en un certificado en Windows, sin confiar en su CA raíz?


¿Es posible hacer que Windows confíe en un certificado, sin que confíe en la CA raíz como una CA raíz confiable?

Digo que tengo la siguiente cadena de certificado,

Dept-Root-CA
Dept-Intermediate-1
Server-Certificate

Quiero confiar en el Certificado del servidor, pero no quiero confiar en Dept-Root-CA porque podría firmar cualquier certificado y mis servidores confiarían en él. El hecho de que esté dispuesto a confiar en el certificado en Servidor-Certificado para una operación específica, no significa que esté dispuesto a confiar en que Dept-Root-CA se haya asegurado correctamente.

Gracias


9
2018-03-21 22:26


origen


¿Para qué exactamente quieres confiar en eso? HTTPS? ¿O alguna otra cosa? Ahí son formas de indicar que desea aceptar un solo certificado sin aceptar nada más de la CA raíz, pero depende de lo que esté haciendo. (Aún obtendrá errores si intenta validar el certificado) - Mark Henderson♦
Esencialmente sí. Si fuera un código personalizado, no sería un problema, pero esto es usar ADFS 2 y lo único que puedo hacer con respecto a cómo trata los certificados es cómo el servidor confía en ese certificado. También hay otros casos, pero este es solo el ejemplo actual. - bkr


Respuestas:


No. Mientras el certificado diga "Emitido por: xxx", también debe confiar en xxx, hasta el final de la cadena. Si se trata de un certificado autofirmado, puede colocarlo en el almacén de CA raíz de confianza y, dado que es emitido y emitido por la misma entidad, debe ser de confianza.

Pero no, por lo general, no es factible ni aconsejable eludir completamente todo el propósito de la seguridad basada en certificados.


5
2018-03-21 22:41



Tenía miedo de eso. Aunque no lo llamaría eludir. Solo porque quiero un canal seguro para hablar con una máquina en un grupo organizativo diferente no significa que quiera confiar en su CA. - bkr
Correcto ... pero la CA firmó ese certificado, y sin ese certificado CA, el otro extremo puede seguir cambiando su certificado. - SpacemanSpiff
No estoy seguro de entender lo que estás diciendo. Quiero confiar explícitamente en su certificado. Si fue cambiado, me gustaría tener que confiar explícitamente otra vez. Básicamente quiero el modelo de certificado de confianza como el que hay en Firefox. En Firefox, si el certificado no es válido según las CA de confianza existentes, puede elegir confiar en él de todos modos; si cambia, tendrá que elegir confiar en el nuevo certificado porque no se ha confiado explícitamente en él. - bkr
just keep changing their certificate Si el extremo remoto cambió su certificado, entonces no coincidirá con el que guardó. Si ignora todo el negocio de CA, ¿no lo está tratando como si fuera una clave de host SSH? - Zoredache
De manera realista, solo lo cambiarán una vez cada 2 años. El producto MS que estoy usando requiere que la conexión se asegure a través de https. por lo que tiene que ser de confianza. porque está firmado con su CA Tendría que confiar en su CA: no quiero hacerlo porque eso les permitiría falsificar cualquier certificado de mi servidor, en lugar de permitirles una interacción limitada con un nombre de host específico. - bkr


Bien .... tu podría capturar esa información de confianza de otra manera.

Es, desafortunadamente, un poco complicado.

Cree su propia CA, luego cree su propio emisor de firma cruzada para Dept-Intermediate-1 (o Dept-Root-CA) firmando su certificado con su CA, posiblemente agregando restricciones de dominio. Si el "real" Dep-Intermedio-1 está desactivado (preferiblemente) o no se conoce, las ventanas usarán su cadena de confianza.

Vea mi otra respuesta aquí: Restringir un certificado raíz a un dominio

Así es como se supone que funcionan los certificados, utilizando firmas digitales para representar una afirmación de propiedad clave. Dado que desea afirmar que el certificado y la clave pertenecen al servidor, debe firmarlo usted mismo, bajo su autoridad, y luego decirle al sistema que confíe en usted.

Todavía hay mucha utilidad en un certificado sin una jerarquía de CA, por encima de lo que proporcionan las claves SSH; parte de eso son las restricciones sobre ellos. Uso de claves, fechas de validez, información de revocación, restricciones de dominio, etc. La otra parte es la información de identificación; servidor que posee la clave, identidad del emisor, políticas de CA aplicadas, información de almacenamiento de claves, etc.


4
2017-11-03 22:23



Esto es interesante. Tendré que encontrar algo de tiempo para intentar realizar este proceso y ver si puedo hacer que funcione. - bkr