OpenSSL devuelve un certificado SSL diferente al que muestra Chrome

13

Al consultar la URL de 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 en 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 utilizando OpenSSL.

EDITAR : he verificado que lo mismo ocurre con OpenSSL en un servidor en un centro de datos remoto que tiene una conexión directa a Internet sin servidores proxy o filtros involucrados.

EDITAR : el problema se debe a SNI, según lo aceptado, 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 de Nombre de Servidor SSL (SNI) al servidor de origen y hará que dicho soporte sea un poco más difícil. Sin embargo, el reenvío de 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

Geoffrey
fuente

Respuestas:

23

CloudFront usa SNI, una forma de poder usar múltiples certificados en una sola 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
Dennis Kaarsemaker
fuente
2
Yaaay Dennis, ese es mi " oooh, no sabía eso " ordenado para SF hoy, ¡y aún no son las 9 am! +1 de mi parte
MadHatter
9

Chrome admite SNI y le dice al servidor qué certificado enviar. El s_clientcomando no lo hace.

Hay más detalles sobre el uso de SNI de CloudFront aquí .

Cuando usa SNI Custom SSL, es posible que algunos usuarios no puedan acceder a su contenido porque algunos navegadores más antiguos no son compatibles con 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 nuestra página de preguntas frecuentes .

y:

SNI Custom SSL se basa en la extensión SNI del protocolo de seguridad de la capa de transporte, que permite que varios dominios sirvan el tráfico SSL a través de la misma dirección IP al incluir los nombres de host a los que los espectadores intentan conectarse. Al igual que con SSL personalizado de IP dedicado, CloudFront ofrece contenido de cada ubicación de borde de Amazon CloudFront y con la misma seguridad que la función SSL personalizada de IP dedicado. SNI Custom SSL funciona con la mayoría de los navegadores modernos, incluyendo Chrome versión 6 y posterior (que se ejecuta en Windows XP y posterior o OS X 10.5.7 y posterior), Safari versión 3 y posterior (que se ejecuta en Windows Vista y posterior o Mac OS X 10.5. 6. y posterior), Firefox 2.0 y posterior, e Internet Explorer 7 y posterior (que se ejecuta en Windows Vista y posterior). 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.

David Schwartz
fuente
s_client soporta SNI muy bien ...
Dennis Kaarsemaker
+1 de mí de todos modos, debido a la excelente documentación que se muestra.
MadHatter
No dije s_clientque no era compatible con CLI. Dije que el s_clientcomando (en el OP) no.
David Schwartz
@DavidSchwartz: en realidad, mi cliente OpenSSL admite SNI y puedo verificarlo utilizando la información que se describe aquí.
Geoffrey
@ Geoffrey, estoy de acuerdo. Es el comando en el OP que no admite SNI.
David Schwartz