¿Debería 'openssl Verify' reconocer una restricción de 'Longitud de ruta' excedida en una CA raíz / intermedia?

4

Fondo

Siguiendo las guías aquí y aquí Estoy configurando un PKI multinivel. He aumentado la configuración de pathlen a 3, de modo que puedo generar un certificado raíz que puedo usar para firmar el primer intermedio y almacenar de forma segura. El primer intermedio se almacenará en la estación de trabajo de configuración y se utilizará para generar segundos intermedios, que se utilizarán para generar los certificados finales que realmente se utilizan para la comunicación dentro de un clúster remoto.

/ Fondo

Al experimentar con esto, descubrí que si reduzco el valor de pathlen usado para generar la CA, incluso a 0, en un comando como este:

openssl verify -CAfile <root ca> -untrusted <chain of intermediates> \
    <cert to verify>

el certificado todavía se valida como correcto.

Desde que hice una pregunta sobre esto here También configuré una cadena de confianza similar con openssl (1 CA, 2 CA intermedias, 1 certificado de servidor) y asigné el pathlen" 1 "a la CA, y pathlen" 0 "a ambos intermedios ( un intermedio fue firmado por el otro). openssl verify todavía dijo que esto estaba bien.

Habría esperado que la longitud máxima de ruta de la CA hiciera inválidos los certificados en ambos casos, ¿esto es incorrecto?

Actualización: Resultado (con suerte para ilustrar el entendimiento que he ganado)

Resulta que cuando estaba verificando la cadena que configuré a través de openssl, estaba verificando el segundo certificado de confianza subordinado, en lugar del certificado del servidor (hoja). Cuando configuro una cadena de los dos subordinados para pasar al indicador -untrusted y verifiqué el certificado del servidor, openssl (correctamente) lo rechaza como no válido.

Esto significa que el número mínimo de fideicomisos para un certificado válido donde se impone una restricción de ruta de acceso es 2: la CA raíz (autofirmada), donde se ignora cualquier valor de ruta de acceso, y un certificado intermedio (que puede tener una ruta de acceso) valor de 0 como mínimo). Tenga en cuenta que aunque el pathlen es 0, este certificado puede seguir firmando un certificado válido, ya que la restricción de pathlen solo se aplica al número de nodos en la cadena de confianza del certificado, no al certificado en sí mismo.

El autor de los artículos que estaba utilizando como fuente de información sobre esto se equivoca. Además, la forma en que cfssl en el momento de la escritura está configurada para aceptar un valor de pathlen solo para un valor CA autofirmado (no para cualquier CA subordinada) hace que esto sea aún más opaco, y probablemente causó la confusión por parte del autor.

En retrospectiva, tiene sentido que no sea necesario aplicar un valor de pathlen a una CA raíz, ya que la CA es en última instancia confiable (o debería ser para que cualquier certificado firmado sea válido). Está en la autoridad que mantiene la clave de la CA raíz para firmar cualquier CSR que solicite el estado de la CA o no (incluida la verificación del valor del pathlen), según su política.

    
pregunta Benjamin 06.04.2016 - 00:01
fuente

1 respuesta

4

La restricción pathlen solo es válida en certificados de CA subordinados.

Si siguió el primer artículo que vinculó y generó un ancla de confianza con una restricción pathlen , no se verificará.

Según RFC5280 sección 6.1.4 (k) basicConstraint solo se incluye en el certificado i+1 (donde el ancla de confianza es el primero ( i=1 ) y los certificados subsiguientes en el algoritmo son i=2 , i=3 y así sucesivamente). Es decir, no lo verifique en el ancla de confianza, solo verifíquelo en certificados de CA subordinados.

    
respondido por el garethTheRed 06.04.2016 - 09:56
fuente

Lea otras preguntas en las etiquetas