Desabilitando o SNI para virtualhost específico no Apache

Question

Temos um servidor da Web com alguns IPs da Internet.

Eu configurei com sucesso virtualhosts baseados em nome SNI, está funcionando muito bem. O que eu gostaria de fazer é que nosso site principal NÃO use SNI e use apenas um dos endereços IP exclusivos para que nosso suporte a navegadores para esse site seja melhorado (combinações XP / IE ...)

Desenvolvemos um site muito popular, com uma quantidade significativa de usuários executando navegadores desatualizados, por isso é muito importante para nós.

Executando o Apache 2.2 (2.2.15-47.el6_7) no CentOS 6.

    

Answer 1

Como outros afirmaram, basta colocar o primeiro site como o primeiro host virtual e ele funcionará se o SNI estiver ativado ou não:

<VirtualHost *:443>

   ServerName www.site1.com

   DocumentRoot /site1/

   SSLCertificateKeyFile /ssl/server1.key
   SSLCertificateFile /ssl/server1.crt

</VirtualHost>

<VirtualHost *:443>

   ServerName www.site2.com

   DocumentRoot /site2/

   SSLCertificateKeyFile /ssl/server2.key
   SSLCertificateFile /ssl/server2.crt

</VirtualHost>

No entanto, os navegadores não-SNI para o site 2 receberão o certificado de site1 e, assim, haverá erro (e os usuários poderão se perguntar por que receberam um certificado para um site diferente, embora se ainda estiverem em navegadores não-SNI provavelmente não é especialista em tecnologia).

No entanto, é possível fornecer acesso a todos usuários para todos seus sites, apesar do aparente problema de SNI, se você tiver um único certificado que cubra todos os sites campo de nome alternativo do assunto.

Você pode ter dois hosts virtuais usando a mesma chave e certificado:

<VirtualHost *:443>

   ServerName www.site1.com

   DocumentRoot /site1/

   SSLCertificateKeyFile /ssl/server.key
   SSLCertificateFile /ssl/server.crt

</VirtualHost>

<VirtualHost *:443>

   ServerName www.site2.com

   DocumentRoot /site2/

   SSLCertificateKeyFile /ssl/server.key
   SSLCertificateFile /ssl/server.crt

</VirtualHost>

Então você tem a mesma chave e certificado para dois sites (ou três, ou mais, se quiser).

Portanto, o site www.site1.com sempre funciona como, mesmo sem suporte a SNI, é o host padrão.

Para www.site2.com, fica mais interessante:

• Para navegadores que suportam SNI, eles fornecem o nome do servidor e vão direto para a configuração do host virtual site2 e isso funciona.
• Para navegadores que não suportam SNI, eles são padronizados para a configuração do site1, que retorna seu certificado, mas como o certificado funciona para ambos os sites, isso é realmente bom. Depois que a negociação de SSL é concluída, a primeira solicitação da Web é enviada, mas, como esse servidor recebe o nome do servidor, ela pode servir corretamente o documento do diretório / site2 /.

Isso funciona porque uma conexão https envolve duas etapas distintas e não relacionadas: 1) fazer negociação SSL e 2) solicitar documento usando essa conexão SSL, e essas duas etapas não precisam ser do mesmo host virtual (embora a maioria das pessoas suponha que sim).

A principal desvantagem dessa opção é que, dependendo da proximidade dos sites, pode parecer pouco profissional ter duas URLs diferentes no mesmo certificado. No entanto, presumivelmente, se eles estão compartilhando um host, eles são empresas um pouco relacionadas (a menos que o servidor seja de propriedade de uma empresa de hospedagem), portanto, isso pode não ser um problema.

Acho isso uma pequena solução útil, especialmente para servidores dev onde eu poderia hospedar vários sites em um endereço IP, onde eu uso centavos autoassinados com vários URLs no campo de nome alternativo do assunto.

    

Answer 2

Você não "desabilita" o SNI no lado do servidor - você não pode nem mesmo controlar se o cliente envia ou não a extensão. Tudo o que você pode fazer é definir como seu servidor responde à presença (ou ausência) de informações do SNI.

Normalmente, quando um servidor recebe uma solicitação sem informações SNI, ele seleciona um dos certificados disponíveis para apresentar ao cliente. Para o Apache, ele será o primeiro vhost para o par endereço / porta que está sendo ouvido.

Quanto a ter ou não um endereço "não-SNI" separado para o site que você deseja tornar seguramente acessível sem o SNI, não acho que seja importante. Você também pode salvar um endereço IPv4 valioso e colocá-los todos no mesmo IP. Qualquer pessoa que acesse um site somente SNI de um navegador que não seja da SNI receberá os mesmos avisos de certificado, independentemente de seu endereço não ser o mesmo da SNI ou não. A única consideração é se você deseja ou não o certificado para o site que suporta clientes não-SNI sendo apresentados a clientes não-SNI quando eles acessam um site somente SNI.

Eu já digitei "SNI" tantas vezes, está começando a perder todo o sentido ...