Al consultar la URL CDN de Sparkfun usando OpenSSL con el siguiente comando:
openssl s_client -showcerts -connect dlnmh9ip6v2uc.cloudfront.net:443
El nombre común devuelto en el certificado es *.sparkfun.com, que no se puede verificar, pero si carga el host en Chrome, el nombre común que se muestra es*.cloudfront.net
¿Que esta pasando aqui?
Esto está causando un problema porque el entorno en el que estoy proporciona proxy SSL a través de Squid SSL_Bump, que genera un certificado firmado por mi CA de confianza local para el dominio. Esto funciona para todos los dominios excepto los anteriores, ya que el CN no coincide ya que el nuevo certificado se genera mediante OpenSSL.
EDITAR- He verificado que ocurre lo mismo con OpenSSL en un servidor en un centro de datos remoto que tiene una conexión directa a Internet sin servidores proxy ni filtrado.
EDITAR- El problema se debe a SNI, como se aceptó, pero para completar la información de por qué causa un problema con Squid y SSL_Bump:
Este proyecto no admitirá el reenvío de información de indicación del nombre del servidor SSL (SNI) al servidor de origen y dificultará un poco dicho soporte. Sin embargo, el reenvío SNI tiene sus propios desafíos serios (más allá del alcance de este documento) que superan con creces las dificultades de reenvío adicionales.
Tomado de:http://wiki.squid-cache.org/Features/BumpSslServerFirst
Respuesta1
CloudFront utiliza SNI, una forma de poder utilizar varios certificados en una única IP. Todos los navegadores modernos admiten esto, al igual que el comando s_client de openssl, pero s_client no hace esto mágicamente. Tienes que decirle que lo use:
openssl s_client -servername dlnmh9ip6v2uc.cloudfront.net -connect dlnmh9ip6v2uc.cloudfront.net:443 -showcerts
Respuesta2
Soportes de ChromeSNI, indicando al servidor qué certificado enviar. El s_clientcomando no.
Hay más detalles sobre el uso de SNI por parte de CloudFrontaquí.
Cuando utiliza SNI Custom SSL, es posible que algunos usuarios no puedan acceder a su contenido porque algunos navegadores más antiguos no admiten SNI y no podrán establecer una conexión con CloudFront para cargar la versión HTTPS de su contenido. Para obtener más información sobre SNI, incluida una lista de navegadores compatibles, visite nuestroPreguntas más frecuentespágina.
y:
SNI Custom SSL se basa en la extensión SNI del protocolo Transport Layer Security, que permite que múltiples dominios sirvan tráfico SSL a través de la misma dirección IP al incluir el nombre de host al que los espectadores intentan conectarse. Al igual que con SSL personalizado de IP dedicada, CloudFront ofrece contenido desde cada ubicación de borde de Amazon CloudFront y con la misma seguridad que la función SSL personalizado de IP dedicada. SNI Custom SSL funciona con la mayoría de los navegadores modernos, incluido Chrome versión 6 y posteriores (que se ejecuta en Windows XP y posteriores o OS X 10.5.7 y posteriores), Safari versión 3 y posteriores (que se ejecuta en Windows Vista y posteriores o Mac OS X 10.5. 6. y posteriores), Firefox 2.0 y posteriores, e Internet Explorer 7 y posteriores (ejecutándose en Windows Vista y posteriores). Los navegadores más antiguos que no admiten SNI no pueden establecer una conexión con CloudFront para cargar la versión HTTPS de su contenido. SNI Custom SSL está disponible sin costo adicional más allá de las tarifas de solicitud y transferencia de datos estándar de CloudFront.