O OpenSSL retorna um certificado SSL diferente daquele mostrado pelo Chrome

Question

Ao consultar a URL do 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 ser 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 que eu estou no 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, mas acima, pois o CN não corresponde, pois o novo certificado é gerado usando o OpenSSL.

EDIT - Eu verifiquei o mesmo ocorre com o OpenSSL em um servidor em um centro de dados remoto que tem uma conexão direta com a Internet sem proxies ou filtragem envolvidos.

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

This project will not support forwarding of SSL Server Name Indication (SNI) information to the origin server and will make such support a little more difficult. However, SNI forwarding has its own serious challenges (beyond the scope of this document) that far outweigh the added forwarding difficulties.

Extraído de: link

    

Answer 1

O CloudFront usa o 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 magicamente isso. Você tem que dizer para usá-lo:

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

    

Answer 2

O Chrome suporta SNI , informando ao servidor qual certificado deve ser enviado. O comando s_client não.

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

When you use SNI Custom SSL, some users may not be able to access your content because some older browsers do not support SNI and will not be able to establish a connection with CloudFront to load the HTTPS version of your content. For more information on SNI, including a list of supported browsers, please visit our FAQ page.

e:

SNI Custom SSL relies on the SNI extension of the Transport Layer Security protocol, which allows multiple domains to serve SSL traffic over the same IP address by including the hostname viewers are trying to connect to. As with Dedicated IP Custom SSL, CloudFront delivers content from each Amazon CloudFront edge location and with the same security as the Dedicated IP Custom SSL feature. SNI Custom SSL works with most modern browsers, including Chrome version 6 and later (running on Windows XP and later or OS X 10.5.7 and later), Safari version 3 and later (running on Windows Vista and later or Mac OS X 10.5.6. and later), Firefox 2.0 and later, and Internet Explorer 7 and later (running on Windows Vista and later). Older browsers that do not support SNI cannot establish a connection with CloudFront to load the HTTPS version of your content. SNI Custom SSL is available at no additional cost beyond standard CloudFront data transfer and request fees.