Certificados SSL de raíz y soporte de navegador

6

He dado tres certificados para instalar en nginx

AddTrustExternalCARoot.crt
PositiveSSLCA2.crt
www_example_com.crt

Así que los convierto en un certificado encadenado

cat  www_example_com.crt PositiveSSLCA2.crt AddTrustExternalCARoot.crt > example.com.cert

Mis preguntas:

  1. ¿Es realmente necesario agregar AddTrustExternalCARoot.crt para los navegadores modernos?
  2. Si omito el AddTrustExternalCARoot.crt , ¿habrá alguna posibilidad de que algunos navegadores muestren una advertencia? ¿Veo algún lugar donde se vea la matriz de compatibilidad del navegador de certificados raíz?
  3. Por qué la empresa SSL sigue enviando AddTrustExternalCARoot.crt si no es necesario.
pregunta Howard 26.07.2013 - 06:23
fuente

2 respuestas

5

Nominalmente, en la filosofía "X.509" pura, el cliente SSL debe obtener el certificado del servidor y todos los certificados de CA intermedios necesarios de la forma que crea conveniente, pero en particular, hablando con el Directorio , que es el servidor LDAP mundial gigante que contiene todo.

Desafortunadamente, el Directorio nunca existió (demasiado centralizado, demasiado complejo), por lo que los protocolos prácticos deben incluir alguna disposición para el envío de certificados. Sucede lo mismo en SSL / TLS : el servidor envía su propio certificado y un montón de otros certificados que "pueden ayudar" al cliente. De hecho, el estándar TLS incluso especifica que el servidor DEBE enviar una cadena lista para validar:

certificate_list
  This is a sequence (chain) of certificates.  The sender's
  certificate MUST come first in the list.  Each following
  certificate MUST directly certify the one preceding it.  Because
  certificate validation requires that root keys be distributed
  independently, the self-signed certificate that specifies the root
  certificate authority MAY be omitted from the chain, under the
  assumption that the remote end must already possess it in order to
  validate it in any case.

En particular, observe que la propia raíz autofirmada puede o no estar incluida. Esta raíz nunca es necesaria del lado del cliente (y nunca lo ha sido), pero enviarla es "tradicional" (una de las innumerables tradiciones en TI; no es útil, pero en su mayoría es inofensiva).

El cliente debe poder validar la cadena de certificados "tal como está" y está permitido (como en "moralmente justificado"), según el estándar TLS, para rechazar el protocolo de enlace si se envió la cadena exacta por el servidor no puede ser validado. Sin embargo, al cliente también se le permite (y se le recomienda) que intente reconstruir otra cadena y validar eso, si lo que el servidor envió no era directamente utilizable. Los navegadores modernos hacen eso; intentarán utilizar certificados de CA intermedios conocidos localmente (obtenidos en la instalación o almacenados en caché) y también pueden descargar certificados de CA adicionales, siguiendo la URL que se encuentra en los certificados ( Authority Information Access extension). Al menos IE en Windows (reciente) hará eso, pero, para evitar una situación desagradable de gallina y huevo, solo seguirá la URL http:// , no https:// . Estas descargas adicionales pueden tomar algún tiempo y hacer que el apretón de manos sea menos robusto, en caso de una red inestable o un tiempo de espera.

Resumen: el envío de la raíz no es obligatorio, pero es tradicional (es improbable que la sobrecarga de la red de 1 kB por saludo completo tenga un impacto significativo o incluso perceptible en el rendimiento). El envío de la CA intermedia se requiere nominalmente y, en la práctica, se recomienda, aunque los navegadores / sistemas operativos modernos pueden recuperarse mediante el uso de estrategias de creación de cadenas de certificados alternativas.

    
respondido por el Thomas Pornin 26.07.2013 - 15:50
fuente
1

Desde los nombres de los archivos, es imposible saber qué es realmente cada certificado. Así que no puedo ayudar con esos archivos específicos. Pero aquí está la esencia de cómo funcionan los certificados:

  • El navegador tiene un conjunto de certificados de confianza "raíz" que están configurados para confiar. Para que se pueda confiar en cualquier otro certificado, debe haber una ruta de firma que lleve a uno de esos certificados raíz.

  • Tiene un certificado firmado de la autoridad de certificación. Tiene su nombre de dominio.

  • Si su certificado no fue firmado por uno de los certificados raíz de confianza en su navegador, entonces la autoridad de certificados también le enviará al menos un certificado intermedio; uno de los cuales habrá firmado su certificado, uno que haya firmado ese, y así sucesivamente hasta una raíz confiable.

Cuando envía su propio certificado al navegador como parte de la negociación de SSL, si al navegador le falta alguno de los certificados intermedios en la cadena que lleva al certificado raíz, no se puede validar el certificado. Pero si su servidor web también envía el (los) certificado (s) intermedio (s) como parte del inicio de SSL, entonces el navegador puede hacer el enlace.

Entonces, para responder parte de su pregunta, no es necesario que los certificados intermedios estén instalados en el servidor si ya están presentes en la computadora del cliente. Pero como en realidad nunca llegas a ver la computadora del cliente, es mejor estar en el lado seguro.

¿En cuanto a qué son los certificados que te enviaron? Ni idea. Uno es obviamente tu certificado. Al menos uno es probablemente un certificado intermedio. Uno podría realmente ser la "raíz" de confianza que tendría que ya estar presente en la computadora del cliente para que todo su acuerdo de confianza funcione.

En cuanto a por qué te enviaron estos certificados; pregúnteles.

    
respondido por el tylerl 26.07.2013 - 07:42
fuente

Lea otras preguntas en las etiquetas