Ich habe ein Szenario, in dem externe Clients ein anderes Zertifikat erhalten als das, das an die IIS-Site gebunden ist. Dies ist Win2008R2 / IIS in der folgenden Konfiguration:
(Interwebs) --> (LB) --> (IIS-Reverse-Proxy/DMZ) --> (IIS www hostet 2 separate Sites, jede mit eindeutigem FQDN, eindeutiger IP und eindeutigem SSL EV)
Es gibt kein Zertifikat auf dem LB. Es gibt keine Zertifikate auf dem IIS-Rev-Proxy (es handelt sich nur um eine HTTP-Umleitung/URL-Umschreibung).
Auf dem IIS-Server sind (2) Sites konfiguriert, jede mit ihrem eigenen eindeutigen FQDN und dem entsprechenden SSL EV-Zertifikat, das an eine eindeutige IP auf dem Server gebunden ist. Beispiel:
- physische IP = 1.1.1.1
- virtuelle-ip1 = 1.1.1.2
- virtuelle-ip2 = 1.1.1.3
- app.abc.com = 1.1.1.2
- app.xyz.com = 1.1.13
Derzeit erhalten Clients das richtige Zertifikat, wenn sie auf zugreifen app.abc.com, aber wenn sie auf zugreifen app.xyz.com, erhalten sie einen SSL-Zertifikatfehler wegen Namenskonflikten, da der FQDN nicht mit dem allgemeinen Namen übereinstimmt. Ich habe überprüft, dass auf dem IIS-Server der FQDN und der allgemeine Name/ausgestellt für des Zertifikats mit dem übereinstimmen, was sie sein sollten.
WOHER kommt dieses Zertifikat? Wenn ich beispielsweise auf dem Client, dem IIS-Server, eine Paketerfassung ausführen würde, woher würde Ihrer Meinung nach das Zertifikat beim Filtern des SSL-Verkehrs angezeigt?
(Entschuldigung, falls hier Informationen fehlen)