
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_client
comando 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.