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
fuente
Chrome admite SNI y le dice al servidor qué certificado enviar. El
s_client
comando no lo hace.Hay más detalles sobre el uso de SNI de CloudFront aquí .
y:
fuente
s_client
que no era compatible con CLI. Dije que els_client
comando (en el OP) no.