Wir haben eine Nginx-Instanz mit mehreren virtuellen Hosts auf derselben IP-Adresse. Sie nginx.conf
hat eine ähnliche Konfiguration wie die folgende:
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;
}
...
Jede Domain hat ihr eigenes SSL-Zertifikat. Alle Zertifikate werden auf SSLLabs.com mit A+ bewertet. Allerdings werden sie alle als inkompatibel mit Browsern ohne SNI-Unterstützung angezeigt (z. B. IE8 unter WinXP).
Benutzer können normalerweise problemlos auf http(s)://www.primary.com
, http(s)://www.secondary.com
, , usw. zugreifen. Einige IE9-Benutzer unter Windows 7 64-Bit beschweren sich jedoch, dass sie eine Sicherheitswarnung (ungültiges Zertifikat) erhalten, wenn sie versuchen, auf oder zuzugreifen. Wenn sie die Sicherheitswarnung ignorieren und fortfahren, wird die URL problemlos geöffnet. Wenn sie dann das Zertifikat in der Adressleiste des Browsers prüfen, wird das Zertifikat für anstelle des Zertifikats für die angeforderte Domäne angezeigt. Dieselben Benutzer haben auf derselben Maschine keine Probleme mit anderen Browsern wie Firefox, Chrome oder Opera. Kein anderer Benutzer hat Fehler gemeldet (IE10, IE11, Safari, Windows 8, Mac OS usw.). Beachten Sie auch, dass nicht alle IE9-Benutzer diese Probleme haben. Wir haben IE9-Benutzer im selben Netzwerk gesehen, die problemlos auf die Websites zugreifen konnten.http(s)://www.tertiary.com
https://www.secondary.com
https://www.tertiary.com
www.primary.com
Da sich die Benutzer in einer Unternehmensumgebung befinden, in der die Verwendung des Standardbrowsers (IE9) durch die IT-Richtlinien empfohlen wird, nehmen einige der betroffenen Benutzer die Warnung ernst und weigern sich, die betroffenen Websites weiterhin zu verwenden. Wir haben die regulären Optionen wie das Löschen des Browser-Cache ausprobiert.
Gibt es Ideen oder Hinweise, wie wir die Grundursache finden und beheben können? Wir möchten eine Lösung, die wir serverseitig implementieren können und die kein Eingreifen der Benutzer erfordert (es sei denn, es liegt ein dokumentiertes Problem mit IE9 unter Windows 7 vor).