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

digamos que tengo la siguiente cadena de certificados,

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

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

Gracias

windows ssl

— bkr
fuente

¿Para qué quieres confiar exactamente? HTTPS? O alguna otra cosa? No son formas de indicar que desea aceptar un único certificado sin aceptar nada más de la CA raíz, pero depende de lo que está haciendo. (Todavía obtendrá errores si intenta validar el certificado)

— Mark Henderson

Esencialmente si. Si fuera un código personalizado, entonces no sería un problema, pero esto está usando ADFS 2 y lo único que puedo hacer con respecto a cómo trata los certificados es cambiar la forma en que el servidor confía en ese certificado. También hay otros casos, pero este es solo el ejemplo actual.

— bkr

Respuestas:

No. Siempre y cuando 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 la tienda Trusted Root CAs, y dado que se emite y emite por la misma entidad, entonces debe ser confiable.

Pero no, generalmente no es factible o aconsejable eludir por completo el propósito de la seguridad basada en certificados.

— Ryan Ries
fuente

Tenía miedo de eso. Sin embargo, no lo llamaría eludir. El hecho de que quiera 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 de 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 se cambiara, me gustaría tener que volver a confiar explícitamente en él. Básicamente quiero el modelo de confianza de certificados como el que hay en Firefox. En Firefox, si el certificado no es válido bajo las CA confiables 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.

— bkr

just keep changing their certificateSi el extremo remoto cambió su certificado, entonces no coincidiría con el que guardó. Si ignora todos los negocios de CA, ¿no lo está tratando como una clave de host SSH?

— Zoredache

de manera realista, solo lo cambiarán una vez cada 2 años. el producto de MS que estoy usando requiere que la conexión esté segura a través de https. así que hay que confiar en él. porque está firmado con su CA, tendría que confiar en su CA; no quiero hacerlo porque eso les permitiría falsificar cualquier certificado a mi servidor, en lugar de permitirles una interacción limitada con un nombre de host específico.

— bkr

Bueno .... Usted podría capturar esa información de confianza de otra manera.

Desafortunadamente, es 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 es desconocido, Windows utilizará 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 de la clave. Como desea afirmar que el certificado y la clave pertenecen al servidor, lo firma usted mismo, bajo su autoridad, y luego le dice 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.

— davenpcj
fuente

Esto es interesante. Tendré que encontrar algo de tiempo para intentar trabajar en este proceso y ver si puedo hacerlo funcionar.

— bkr