Cómo se verifica la cadena de certificados TLS

  

(1) ¿La verificación de la cadena termina allí o continúa hasta que lleguemos a D?

depende de la implementación de motor de encadenamiento de certificados (CCE). Las diferentes plataformas tienen diferentes implementaciones que pueden no ser compatibles con todas las lógicas de validación recomendadas / obligatorias descritas en RFC5280 .

La confianza en el certificado requiere un punto final de la cadena que se presenta en un formulario autofirmado (llamamos a dicho certificado como certificado de CA raíz). Como el certificado B no es autofirmado (está firmado por C), la cadena A-B-C-D no es confiable hasta que C y D se recuperan y validan. Entonces, la respuesta a esta pregunta es: la cadena continúa la validación a la raíz.

Si hablamos de la implementación de Microsoft (solo un ejemplo con el que estoy familiarizado), su CCE crea una o más cadenas (tanto como sea posible) sin realizar una validación inmediata. Solo obtienen certificados e intentan realizar reglas básicas para vincular cada certificado en el lugar correcto de la cadena. Cuando se construyen todas las cadenas, cada una de ellas se valida de acuerdo con las reglas descritas en RFC5280. Una vez validado, puede darse el caso de que haya varias cadenas confiables y válidas. CCE utiliza su propia lógica de selección para seleccionar solo una cadena de una colección de cadenas.

Cuando hablamos de tiendas de certificados en los navegadores, se utilizan para:

1. establecer una confianza para una CA raíz de confianza particular (almacén de CA raíz de confianza). Estos certificados DEBEN presentarse en un formulario autofirmado. De lo contrario, no se pueden utilizar como punto final de la cadena y la confianza no se establece (aunque el certificado intermedio se instala en el almacén raíz).
2. ayude a CCE a construir rápidamente la cadena sin tener que descargar certificados faltantes de Internet, porque están disponibles localmente. Algunos brwosers carecen por completo de capacidad para procesar la extensión Authority Information Access , lo que significa que el cliente SSL puede obtener certificados de CA solo de dos fuentes: protocolo de enlace SSL, almacén de certificados local.

  

(2) Cuando un servidor presenta su cadena de certificados al navegador, ¿también presenta el certificado raíz D o solo presenta A-B-C?

depende de la implementación de un servidor web. Una referencia de RFC 5246 §7.4.2 :

  

lista de certificados         Esta es una secuencia (cadena) de certificados. El remitente         El certificado DEBE estar primero en la lista. Cada siguiente         El certificado DEBE certificar directamente el que lo precede. Porque         la validación de certificados requiere que las claves raíz sean distribuidas         independientemente, el certificado autofirmado que especifica la raíz         La autoridad de certificación PUEDE ser omitida de la cadena, bajo el         supuesto de que el extremo remoto ya debe poseerlo para poder         Valídalo en cualquier caso.

RFC sugiere que el certificado de CA raíz PUEDE O NO PUEDE enviarse al cliente. Como resultado, al desarrollar un cliente SSL, debe esperar que el certificado raíz se envíe a lo largo de la cadena. Dos servidores web principales: Apache e IIS de forma predeterminada NO envían el certificado raíz durante el protocolo SSL.

1) Si el certificado intermedio (B) es de confianza, es decir, es un certificado de firma válido, no caducado, no manipulado y no revocado, entonces estar en el almacén de confianza es suficiente para que el cliente TLS no lo haga. No es necesario continuar en la cadena para verificar el certificado de la hoja.

Sin embargo , esa cosa "no manipulada" requiere que un certificado de confianza haya firmado el certificado intermedio. Ahora, el certificado intermedio podría ser autofirmado, al igual que los certificados de raíz, además de ser parte de una cadena hasta los certificados de raíz. En ese caso (asumiendo que la firma se retira), no hay necesidad de verificar la cadena por encima del certificado intermedio.

Es posible que algunos clientes ni siquiera se molesten en verificar que el certificado tenga una firma válida (está en el almacén de confianza, por lo que es confiable, en teoría) o que no haya sido revocado (muchos de los navegadores antiguos no lo hicieron). verifique la revocación de forma predeterminada, asumiendo que se actualizarían con una lista actualizada de certificados revocados que ya no se encuentran en el almacén de confianza). Sin embargo, en la práctica, debe asumir que ambas cosas (la firma válida, incluso si es autofirmada y no revocada) son verificadas por la mayoría de los clientes.

2) Eso depende completamente del servidor. Es típico servir todo excepto el certificado raíz, pero algunos servidores envían toda la cadena. Si utiliza un sitio como Qualys SSLLabs , te mostrará los certificados que envía el servidor. Este sitio parece enviar dos certificados: una hoja comodín para *.stackexchange.com y un intermediario "Servidor CA", pero no el certificado raíz (que es una CA raíz DigiCert EV y firmó el certificado intermedio). Sin embargo, algunos otros sitios envían la cadena completa; SSLLabs lo marcará si lo haces, pero generalmente es un desperdicio.