Por que o apache httpd me diz que meus virtualhosts baseados em nome funcionam apenas com navegadores ativados por SNI (RFC 4366)

Por que o apache me fornece essa mensagem de erro nos meus logs? É um falso positivo?

[warn] Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)

Recentemente, atualizei do Centos 5.7 para 6.3 e, com isso, para uma versão mais recente do httpd. Eu sempre fiz minhas configurações de host virtual ssl como abaixo. Onde todos os domínios que compartilham o mesmo certificado (principalmente / sempre caracteres curinga) compartilham o mesmo IP. Mas nunca recebi essa mensagem de erro antes (ou eu talvez não tenha consultado o suficiente nos meus logs?) Pelo que aprendi, isso deve funcionar sem o SNI (Indicação do nome do servidor)

Aqui estão partes relevantes do meu arquivo httpd.conf. Sem este VirtualHost, não recebo a mensagem de erro.

NameVirtualHost 10.101.0.135:443

<VirtualHost 10.101.0.135:443>
  ServerName sub1.domain.com

  SSLEngine on
  SSLProtocol -all +SSLv3 +TLSv1
  SSLCipherSuite ALL:!aNull:!EDH:!DH:!ADH:!eNull:!LOW:!EXP:RC4+RSA+SHA1:+HIGH:+MEDIUM
  SSLCertificateFile /opt/RootLive/etc/ssl/ssl.crt/wild.fareoffice.com.crt
  SSLCertificateKeyFile /opt/RootLive/etc/ssl/ssl.key/wild.fareoffice.com.key
  SSLCertificateChainFile /opt/RootLive/etc/ssl/ca/geotrust-ca.pem
</VirtualHost>

<VirtualHost 10.101.0.135:443>
  ServerName sub2.domain.com

  SSLEngine on
  SSLProtocol -all +SSLv3 +TLSv1
  SSLCipherSuite ALL:!aNull:!EDH:!DH:!ADH:!eNull:!LOW:!EXP:RC4+RSA+SHA1:+HIGH:+MEDIUM
  SSLCertificateFile /opt/RootLive/etc/ssl/ssl.crt/wild.fareoffice.com.crt
  SSLCertificateKeyFile /opt/RootLive/etc/ssl/ssl.key/wild.fareoffice.com.key
  SSLCertificateChainFile /opt/RootLive/etc/ssl/ca/geotrust-ca.pem
</VirtualHost>

httpd ssl-certificate sni

— Arlukin
fonte

Respostas:

Isso ocorre porque a diretiva VirtualHost não corresponde à diretiva ServerName e / ou ao CN do certificado. Todos os três precisam ser idênticos, a menos que você tenha um certificado curinga em que as partes não curinga devam ser idênticas.

— bahamat
fonte

Então a resposta aqui é mudar a <VirtualHost 10.101.0.135:443>linha para ser <VirtualHost sub2.domain.com:443>? Potencialmente?

— 22714

@MichaelJones isso resolveu o problema?

— Fernando Santiago

@FernandoSantiago Agora pago por endereços IP diferentes para meus hosts virtuais agora, pois achei o SNI insuficientemente confiável. E eu tenho esses endereços IP nas minhas VirtualHostdeclarações.

— 22815 MichaelJones #

Isso resolveu perfeitamente meu problema. Eu estava usando um VirtualHostcuringa, mas a ServerNamediretiva corresponde ao certificado CN. Todos os 3 combinaram e viola! PS: Esta resposta serverfault.com/questions/578061/… informa como obter o CN que você colocou no seu certificado RSA

— 3bdalla

Não é um erro, é uma mensagem de aviso.

E você está conseguindo porque 1) você atualizou sua versão do Apache e 2) você tem 2 SSL VirtualHosts usando o mesmo endereço IP exato (em vez de usar 2 IPs).

Como você está compartilhando o IP, navegadores sem suporte SNI obterão o primeiro site e nunca o segundo.

— coisa certa
fonte

Navegadores sem SNI obterão o certificado configurado para o primeiro site - mas, na verdade, mapeá-los para um vhost para atender à solicitação, o Hostcabeçalho é verificado normalmente.

— Shane Madden

@ShaneMadden, não acredito que esteja correto, pois o cabeçalho Host: NÃO é verificado ANTES da conexão SSL ser estabelecida. E esse é o objetivo de ter suporte SNI. Ou precisando de 1 IP por SSL VH, caso contrário. Portanto, sem o SNI, o Apache usará como padrão o primeiro VH encontrado com esse endereço IP, o cabeçalho Host: é praticamente ignorado.

— rightstuff

... Caso contrário, você poderá executar centenas de SSL NameBasedVirtualHosts em um único endereço IP e sabemos que isso não é verdade (sem o suporte SNI por servidor e cliente).

— rightstuff

Otherwise you could do 100s of SSL NameBasedVirtualHosts on 1 single IP address, and we know that's not true (without SNI support by server and client)

Você pode. O uso normal disso é quando todos têm o mesmo certificado, um curinga ou um certificado de nome alternativo normalmente. Mas digamos que você tenha dois vhosts com certificados SSL próprios - domain1.com e domain2.com, com domain1.com configurado primeiro. Um navegador não compatível com SNI solicita domain2.com - eles recebem um erro de incompatibilidade de domínio de certificado, porque receberam o certificado domain1 - mas, se clicarem nele, obterão o conteúdo domain2.

— Shane Madden

Se o cabeçalho do host fosse ignorado, mesmo o caso simples e amplamente implantado de "um certificado curinga com vários fantasmas baseados em nome" seria interrompido. De qualquer forma, aqui estão alguns exemplos de perguntas que eu respondi aqui onde esse comportamento foi exibido; serverfault.com/q/292637 serverfault.com/q/330212

— Shane Madden