O OpenSSL retorna um certificado SSL diferente daquele mostrado pelo Chrome

Ao consultar o URL da CDN do Sparkfun usando o OpenSSL com o seguinte comando:

openssl s_client -showcerts -connect dlnmh9ip6v2uc.cloudfront.net:443

O nome comum retornado no certificado é *.sparkfun.com, que falha ao verificar, mas se você carregar o host no Chrome, o nome comum mostrado é*.cloudfront.net

O que está acontecendo aqui?

Isso está causando um problema porque o ambiente em que estou nos proxies SSL via Squid SSL_Bump, que gera um certificado assinado pela minha CA localmente confiável para o domínio. Isso funciona para todos os domínios, exceto o acima, pois o CN não corresponde à medida que o novo certificado é gerado usando o OpenSSL.

EDIT - Verifiquei o mesmo com o OpenSSL em um servidor em um datacenter remoto que possui uma conexão direta com a Internet sem proxies ou filtros envolvidos.

EDIT - O problema é devido ao SNI, conforme aceito, mas para preencher as informações sobre o motivo pelo qual causa um problema com o Squid e o SSL_Bump:

Este projeto não suporta o encaminhamento de informações SNI (SSL Server Name Indication) para o servidor de origem e dificulta um pouco esse suporte. No entanto, o encaminhamento do SNI tem seus próprios desafios sérios (além do escopo deste documento) que superam em muito as dificuldades adicionais de encaminhamento.

Retirado de: http://wiki.squid-cache.org/Features/BumpSslServerFirst

O CloudFront usa SNI, uma maneira de poder usar vários certificados em um único IP. Todos os navegadores modernos suportam isso, assim como o comando s_client do openssl, mas o s_client não faz isso magicamente. Você precisa dizer para usá-lo:

openssl s_client -servername dlnmh9ip6v2uc.cloudfront.net  -connect dlnmh9ip6v2uc.cloudfront.net:443 -showcerts

O Chrome suporta SNI , informando ao servidor qual certificado enviar. O s_clientcomando não.

Há mais detalhes sobre o uso do SNI pelo CloudFront aqui .

Quando você usa o SNI Custom SSL, alguns usuários podem não conseguir acessar seu conteúdo porque alguns navegadores mais antigos não oferecem suporte ao SNI e não conseguem estabelecer uma conexão com o CloudFront para carregar a versão HTTPS do seu conteúdo. Para mais informações sobre o SNI, incluindo uma lista de navegadores suportados, visite nossa página de Perguntas frequentes .

e:

O SNI Custom SSL depende da extensão SNI do protocolo Transport Layer Security, que permite que vários domínios atendam ao tráfego SSL no mesmo endereço IP, incluindo o nome do host aos quais os visualizadores estão tentando se conectar. Assim como o SSL personalizado IP dedicado, o CloudFront fornece conteúdo de cada local de borda do Amazon CloudFront e com a mesma segurança que o recurso SSL personalizado IP dedicado. O SNI Custom SSL funciona com os navegadores mais modernos, incluindo o Chrome versão 6 e posterior (executando no Windows XP e posterior ou OS X 10.5.7 e posterior), Safari versão 3 e posterior (executando no Windows Vista e posterior ou Mac OS X 10.5. 6. e posterior), Firefox 2.0 e posterior e Internet Explorer 7 e posterior (executando no Windows Vista e posterior). Navegadores mais antigos que não oferecem suporte ao SNI não podem estabelecer uma conexão com o CloudFront para carregar a versão HTTPS do seu conteúdo.