Temos uma instância Nginx com vários hosts virtuais no mesmo endereço IP. nginx.conf
tem configuração semelhante à seguinte:
server {
listen 443 default_server ssl;
server_name www.primary.com;
...
}
server {
listen 80;
server_name .primary.com;
rewrite ^(.*) https://www.primary.com$1 permanent;
}
server {
listen 443 ssl;
server_name www.secondary.com;
...
}
server {
listen 80;
server_name .secondary.com;
rewrite ^(.*) https://www.secondary.com$1 permanent;
}
server {
listen 443 ssl;
server_name www.tertiary.com;
...
}
server {
listen 80;
server_name .tertiary.com;
rewrite ^(.*) https://www.tertiary.com$1 permanent;
}
...
Cada domínio possui seu próprio certificado SSL. Todos os certificados são classificados como A+ em SSLLabs.com. No entanto, todos são mostrados como incompatíveis com navegadores não habilitados para SNI (por exemplo, IE8 no WinXP).
Os usuários normalmente conseguem acessar http(s)://www.primary.com
, http(s)://www.secondary.com
, http(s)://www.tertiary.com
, etc. No entanto, alguns usuários do IE9 no Windows 7 de 64 bits reclamam que recebem um aviso de segurança (certificado inválido) quando tentam acessar https://www.secondary.com
ou https://www.tertiary.com
. Se eles substituirem o aviso de segurança e prosseguirem, o URL será aberto corretamente. Em seguida, verificar o certificado na barra de endereço do navegador mostra o certificado em www.primary.com
vez do domínio solicitado. Os mesmos usuários não enfrentam problemas com nenhum outro navegador como Firefox, Chrome ou Opera na mesma máquina. Nenhum outro usuário relatou erros (IE10, IE11, Safari, Windows 8, Mac OS, etc.). Observe também que nem todos os usuários do IE9 enfrentam esses problemas. Vimos usuários do IE9 na mesma rede que conseguem acessar os sites perfeitamente.
Como os usuários estão em um ambiente corporativo onde o uso do navegador padrão (IE9) é incentivado pelas políticas de TI, alguns dos usuários afetados levam o aviso a sério e se recusam a continuar usando os sites afetados. Tentamos as opções normais, como limpar o cache do navegador.
Alguma ideia ou sugestão sobre como encontrar e corrigir a causa raiz? Gostaríamos de uma solução que pudéssemos implementar no lado do servidor e que não exigisse nenhuma intervenção dos usuários (a menos que haja um problema documentado com o IE9 no Windows 7).