OpenSSL retorna certificado SSL diferente daquele mostrado pelo Chrome

OpenSSL retorna certificado SSL diferente daquele mostrado pelo Chrome

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

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

O nome comum retornado no certificado é *.sparkfun.com, o que não é verificado, mas se você carregar o host no Chrome, o nome comum mostrado será*.cloudfront.net

O que está acontecendo aqui?

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

EDITAR- Verifiquei que o mesmo ocorre com OpenSSL em um servidor em um data center remoto que possui conexão direta com a Internet, sem proxies ou filtragem envolvida.

EDITAR- O problema é por conta do SNI, conforme aceito, mas para preencher as informações do porquê causa problema com o Squid e SSL_Bump:

Este projeto não suportará o encaminhamento de informações de indicação de nome de servidor SSL (SNI) para o servidor de origem e tornará esse suporte um pouco mais difícil. 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.

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

Responder1

O CloudFront usa SNI, uma forma 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 s_client não faz isso magicamente. Você tem que dizer para usá-lo:

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

Responder2

Suporte do ChromeSNI, informando ao servidor qual certificado enviar. O s_clientcomando não.

Há mais detalhes sobre o uso de SNI pelo CloudFrontaqui.

Ao usar o SNI Custom SSL, alguns usuários podem não conseguir acessar seu conteúdo porque alguns navegadores mais antigos não oferecem suporte a SNI e não conseguirão estabelecer uma conexão com o CloudFront para carregar a versão HTTPS do seu conteúdo. Para obter mais informações sobre SNI, incluindo uma lista de navegadores suportados, visite nossoPerguntas frequentespágina.

e:

SNI Custom SSL depende da extensão SNI do protocolo Transport Layer Security, que permite que vários domínios sirvam tráfego SSL no mesmo endereço IP, incluindo o nome do host ao qual os visualizadores estão tentando se conectar. Assim como acontece com SSL personalizado de IP dedicado, o CloudFront entrega conteúdo de cada ponto de presença do Amazon CloudFront e com a mesma segurança que o recurso SSL personalizado de IP dedicado. O SNI Custom SSL funciona com a maioria dos navegadores 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 a SNI não podem estabelecer uma conexão com o CloudFront para carregar a versão HTTPS do seu conteúdo. O SNI Custom SSL está disponível sem custo adicional além das taxas padrão de transferência e solicitação de dados do CloudFront.

informação relacionada