Validación de una cadena de certificados SSL de acuerdo con RFC 5280: ¿Estoy entendiendo esto correctamente?

11

estamos en el proceso de reemplazar los certificados con el hash SHA1 debido al movimiento de Google para que aparezcan menos seguros en Chrome. Los certificados de reemplazo utilizan una CA intermedia diferente a la que estamos usando actualmente, pero la misma CA raíz. Durante las pruebas, notamos que nuestros clientes SSL no validarían la cadena con los nuevos certificados, no entendemos por qué.

Aquí están los detalles:

Actualmente, la cadena que envía el servidor se ve así:

  • CA raíz, firmada por el servidor CA X de la misma autoridad (vino con el certificado del servidor)
  • CA intermedia 1 (vino con certificado de servidor)
  • Certificado de servidor

en nuestros clientes SSL confiamos:

  • CA raíz, autofirmada, pero con el mismo CN y la misma clave (mismo deslizamiento). (Descargado de la autoridad; igual que Mozilla incorpora en sus productos)
  • CA intermedia 1 (idéntica a la que envía el servidor)

Esto funciona con la cadena de certificados actual, pero solo porque confiamos en la CA intermedia 1. Si eliminamos esto, falla porque el servidor CA X no es de confianza. Obviamente, los nuevos certificados no funcionan porque están firmados por una CA intermedia diferente.

Ahora, después de leer RFC 5280, sección 6.1, tengo la impresión de que nuestro cliente SSL no cumple con los estándares, porque de lo que he leído que entiendo la validación de una ruta de certificado es esto (simplificado):

  1. comience con el ancla de confianza; validar si todavía es válido (hora), etc.
  2. para los siguientes certificados: verifique si el CN y la clave del certificado anterior coinciden con los emisores CN y la clave del certificado actual (y verifique las restricciones de acceso, etc.)
  3. el último certificado no debe ser un certificado de CA

El punto es: nuestro cliente SSL no puede validar la cadena porque el certificado raíz que está configurado para usar como un ancla de confianza tiene un emisor diferente al certificado raíz presentado por el servidor. Sin embargo, CN y clave son idénticas para ambos. Desde mi entendimiento de lo que he leído en RFC 5280, el cliente SSL no debería preocuparse por el emisor de su ancla de confianza. Tampoco hay políticas definidas en los certificados dentro de la cadena que puedan hacer cumplir algo así. Sin embargo, no sé si nuestro cliente SSL puede aplicar políticas adicionales que conduzcan a esto (no a mi sistema).

Entonces, mi pregunta es: ¿Nuestro cliente SSL se comporta correctamente en este escenario o no? Y por supuesto: ¿por qué?

Gracias de antemano

Editar: Sé que el servidor debería solo enviar el certificado CA intermedio y no el certificado raíz, sin embargo, estamos usando lo que la autoridad proporcionó como un lío Junto al certificado, que incluía el certificado raíz. Además, por lo que sé, el cliente debe ignorar el certificado raíz enviado por el servidor en ese caso.

También es extraño que el cliente se comporte como si validara la cadena desde el certificado del servidor hasta algo en lo que puede confiar y luego se detiene, mientras que las especificaciones dicen que debería validar la cadena desde el ancla de confianza hasta el certificado del servidor.

Edit2: Las diferentes "versiones" del certificado Root CA tienen el mismo SKID; solo difieren en el número de serie y del emisor (por supuesto).

Además, simplemente pensé que, a partir de la información de la primera edición, parece que el cliente SSL necesita que el certificado raíz de confianza y la cadena sean idénticos en su emisor y posiblemente en el número de serie para aceptarlo.

    
pregunta luxifer 31.10.2014 - 16:28
fuente

2 respuestas

16

Hay X.509 , y hay SSL / TLS . TLS espera que el servidor envíe una cadena de certificados X.509, desde la cual el cliente extraerá la clave pública del servidor. Entonces las cosas divergen:

  • En X.509 puro, el servidor debe enviar su certificado para que el cliente lo valide; posiblemente, el servidor puede agregar un montón desordenado de certificados adicionales que podrían resultar útiles para el cliente, básicamente algunos CA intermedios posiblemente relevantes. El cliente todavía tendría la libertad de validar el certificado de cualquier manera que considere conveniente, en particular a través de la construcción de cadenas arbitrarias. Este método se demuestra, por ejemplo, en CMS (anteriormente conocido como "PKCS # 7"), en el que un el documento ( SignedData ) hace referencia al certificado del firmante y, opcionalmente, incluye un conjunto no ordenado (ASN.1 " SET ") de certificados adicionales.

  • En SSL / TLS, las cosas no van así. En su lugar, el servidor debe enviar la cadena exacta que se va a utilizar; Se permite explícitamente que el servidor omita la CA raíz, pero eso es todo. Cualquier cliente tiene derecho (al menos históricamente, si no de jure ) a rechazar el certificado del servidor si la cadena no coincide con este patrón. Por supuesto, cualquier cliente tiene permiso para hacer un esfuerzo y tratar de validar el certificado del servidor de la forma X.509, con su propia creación de ruta; pero hay clientes SSL que no hacen ese esfuerzo.

Un extracto relevante de RFC 5246 se encuentra en apéndice F.1.1 :

  

Si el servidor está autenticado,      su mensaje de certificado debe proporcionar una cadena de certificado válida      lo que lleva a una autoridad de certificación aceptable.

Este es el pasaje que otorga a los clientes SSL el "derecho" a rechazar sin ceremonias las cadenas de servidores que no se pueden validar "como están".

En su caso, la cadena enviada por el servidor es:

Raíz-X - > CA1 - > Servidor

donde "Root-X" es "la raíz firmada por el servidor CA X". El cliente perezoso intenta validar esa cadena dos veces:

  1. El primer intento se basa en el supuesto de que la cadena incluye la CA raíz. El cliente no encuentra "Root-X" en la lista de su propia CA raíz, por lo que esto falla.

  2. El segundo intento se basa en la suposición de que la cadena no incluye la CA raíz. El cliente escanea su CA raíz en busca de un emisor para Root-X (y ese es el punto crítico). No encuentra ninguno, por lo tanto falla.

Para validar la cadena enviada por su servidor, el cliente debe ser un poco menos vago, y tratar de encontrar un emisor para CA1 dentro de su propio conjunto de CA confiables. Esto requeriría un tercer supuesto, a saber, que la cadena enviada por el servidor incluye una CA raíz, pero no "la correcta".

Supongo que su cliente SSL defectuoso es un "cliente perezoso" como se enuncia más arriba. Para asegurarse, intente conectarse con Internet Explorer como cliente; IE, por todos sus defectos, no es perezoso cuando se trata de la validación de certificados. IE intentará reconstruir una cadena a partir de los certificados enviados por el servidor, los certificados que tiene en sus propias tiendas y los certificados que puede descargar. En particular, cualquier certificado puede contener una URL que apunte al certificado para su emisor (que es parte de la Acceso a la información de la autoridad extensión); IE (y, de hecho, Windows en general) seguirá alegremente dicha URL y recopilará una CA intermedia (solo HTTP, no HTTPS, para evitar un bucle desagradable).

Si, de este modo, puede confirmar que el problema es realmente un cliente vago, las posibles soluciones incluyen las siguientes:

  • Cambie la cadena enviada por el servidor para que incluya la raíz autofirmada o simplemente finalice en CA1.
  • Instale el certificado "Server CA X" como CA de confianza en los clientes.
  • Modificar / configurar el cliente para que no sea perezoso.

Por supuesto, es bastante posible que su cadena sea incorrecta de alguna otra manera, lo que es difícil de evaluar sin ver los certificados. El algoritmo de validación de ruta es complejo, por lo que puede haber otra extensión que no satisfaga al cliente (por ejemplo, una el certificado podría estar usando una extensión Name Constraints en la que la implementación del cliente SSL solo se ahoga). Posiblemente, el cliente no es perezoso, pero insiste en verificar el estado de revocación de todos los certificados en la ruta, y algunos de los respondedores CRL u OCSP están desactualizados o no están disponibles. Existen cientos de formas por las cuales la validación de certificados puede fallar.

    
respondido por el Thomas Pornin 31.10.2014 - 18:16
fuente
2

La cadena provista no debería incluir la raíz, si lo hace, el cliente debe ignorarla. Una característica clave de la confianza X.509 es que requiere raíces pre-conocidas (o anclajes de confianza ). Sin embargo, esta no es la causa de tu problema. El orden se invierte, el certificado del servidor debe ser primero, seguido de su firmante (y su firmante, si es necesario), este podría causar problemas en algunas plataformas, pero siga leyendo.

Los clientes actuales ya no confían en perseguir la cadena por DN (es decir, el nombre del certificado del emisor). Comenzando con el AKID de un certificado (identificador de clave de autoridad), el principal es el certificado con el haciendo coincidir SKID . El SKID (identificador de clave de sujeto) pretende ser un identificador único (estadístico), generalmente se deriva de un hash de la clave pública, pero no es necesario. Para fines de verificación, es simplemente un identificador opaco (es decir, la verificación no lo vuelve a calcular, solo compara los valores). Parece más probable que los identificadores hayan cambiado, aunque los nombres legibles por humanos no lo han hecho.

La comprobación de la cadena debe comenzar en el servidor cert, y trabajar hacia la raíz en la "parte superior", esto es convencionalmente "arriba". Este es el mismo orden en que se presenta la cadena. Cada certificado "sabe" solo su firmante (CN y SKID), nada más acerca de la jerarquía.

Esto amplía un poco el proceso de verificación: Comprobación de la cadena de certificados , y esto da un ejemplo utilizando OpenSSL para reproducir el proceso de verificación típico: enlace

Otro problema posible es lo que constituye el "principio" o "ancla de confianza". Algunas CA tienen un certificado raíz autofirmado (AKID == SKID), algunas usan raíces con firma cruzada (el certificado de firma pertenece a otra CA). Donde exactamente dejar de seguir la cadena es una propiedad del almacén de claves del cliente, generalmente en virtud de un certificado de CA en una clasificación específica.

    
respondido por el mr.spuratic 31.10.2014 - 17:08
fuente

Lea otras preguntas en las etiquetas