Tenemos una instancia de Nginx con múltiples hosts virtuales en la misma dirección IP. nginx.conf
tiene una configuración similar a la siguiente:
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 dominio tiene su propio certificado SSL. Todos los certificados tienen una calificación A+ en SSLLabs.com. Sin embargo, todos se muestran como incompatibles con navegadores no habilitados para SNI (por ejemplo, IE8 en WinXP).
Normalmente, los usuarios pueden acceder a http(s)://www.primary.com
, http(s)://www.secondary.com
, http(s)://www.tertiary.com
, etc. sin problemas. Sin embargo, algunos usuarios de IE9 en Windows 7 de 64 bits se quejan de que reciben una advertencia de seguridad (certificado no válido) cuando intentan acceder https://www.secondary.com
o https://www.tertiary.com
. Si anulan la advertencia de seguridad y continúan, la URL se abre bien. Luego, al verificar el certificado desde la barra de direcciones del navegador se muestra el certificado en www.primary.com
lugar del del dominio solicitado. Los mismos usuarios no enfrentan ningún problema con ningún otro navegador como Firefox, Chrome u Opera en la misma máquina. Ningún otro usuario ha informado de errores (IE10, IE11, Safari, Windows 8, Mac OS, etc.). También tenga en cuenta que no todos los usuarios de IE9 enfrentan estos problemas. Hemos visto usuarios de IE9 dentro de la misma red que pueden acceder a los sitios web perfectamente bien.
Dado que los usuarios se encuentran dentro de un entorno corporativo donde las políticas de TI recomiendan el uso del navegador predeterminado (IE9), algunos de los usuarios afectados toman en serio la advertencia y se niegan a continuar usando los sitios afectados. Hemos probado las opciones habituales, como borrar la memoria caché del navegador.
¿Alguna idea o sugerencia sobre cómo encontrar y solucionar la causa raíz? Nos gustaría una solución que podamos implementar en el lado del servidor y que no requiera ninguna intervención de los usuarios (a menos que haya un problema documentado con IE9 en Windows 7).