6
Zwei Zertifikate für Exchange 2010
Hallo,
ich habe mittlerweile gefühlt halb google durchgelesen und komme vom Verständnis beim Exchange nicht
weiter:
Folgende Situation:
Es gibt eine WAN IP: 80.80.80.80 mit dem DNS Namen exchange.domain.de
Es gibt eine LAN IP: 192.168.1.123 mit dem DNS Namen exchange.domain.local
WAN wird zu LAN durchgenattet
Es gibt kein Proxy, WAF (ist so gewünscht, trotz Sicherheitsbedenken).
Es gibt eine LAN URL auf dem Exchange und eine WAN ULR, die zu den og. Domainnamen passt
Es gibt ein selbstigniertes Zertifikat auf exchange.domain.local, welches auf die Dienste IIS, SMTP, IMAP, POP3 gebunden ist
Exchange 2010 auf Windows 2008 R2
Kann ich mit einer LAN IP zwei SSL Zertifikate binden für beide Domains?
Oder benötige ich ein zusätzliches Netzwerkinterface auf das ich das zweite Zertifikat binde?
Theoretisch kann ich ja den Webserver per WAN IP, LAN IP, WAN DNS und LAN DNS erreichen.
Oder ist das System denn so "schlau" und erkennt anhand des https Requests, welche Domäne aufgerufen wird und
würde dass zur Domäne passende Zertifikat verwenden?
Ich frage, weil ich ja mehrere Zertifikate auch erstellen und an die Dienste binden könnte in der Exchange
Konsole.
Das erschließt sich mir leider nicht so ganz.
Ich hätte jetz gesagt: Ich mache ein Zertifikatsrequest für die externe Domäne in imporitere es dann. Binde es an die Exchange
Dienste. Gehe in den IIS an die Portbindung 443 und erstelle einen zusätzlichen Eintrag für https auf den Hostname und wähle
des Zertifikat für die externe Domäne aus.
Dann wird alle Hostnamen (*) an exchange.domain.local "geschickt" und Hostname exchange.domain.de über das "echte" Zertifikat.
Hat jemand eine Erklärung/Idee
Danke schön, der Lenhart
ich habe mittlerweile gefühlt halb google durchgelesen und komme vom Verständnis beim Exchange nicht
weiter:
Folgende Situation:
Es gibt eine WAN IP: 80.80.80.80 mit dem DNS Namen exchange.domain.de
Es gibt eine LAN IP: 192.168.1.123 mit dem DNS Namen exchange.domain.local
WAN wird zu LAN durchgenattet
Es gibt kein Proxy, WAF (ist so gewünscht, trotz Sicherheitsbedenken).
Es gibt eine LAN URL auf dem Exchange und eine WAN ULR, die zu den og. Domainnamen passt
Es gibt ein selbstigniertes Zertifikat auf exchange.domain.local, welches auf die Dienste IIS, SMTP, IMAP, POP3 gebunden ist
Exchange 2010 auf Windows 2008 R2
Kann ich mit einer LAN IP zwei SSL Zertifikate binden für beide Domains?
Oder benötige ich ein zusätzliches Netzwerkinterface auf das ich das zweite Zertifikat binde?
Theoretisch kann ich ja den Webserver per WAN IP, LAN IP, WAN DNS und LAN DNS erreichen.
Oder ist das System denn so "schlau" und erkennt anhand des https Requests, welche Domäne aufgerufen wird und
würde dass zur Domäne passende Zertifikat verwenden?
Ich frage, weil ich ja mehrere Zertifikate auch erstellen und an die Dienste binden könnte in der Exchange
Konsole.
Das erschließt sich mir leider nicht so ganz.
Ich hätte jetz gesagt: Ich mache ein Zertifikatsrequest für die externe Domäne in imporitere es dann. Binde es an die Exchange
Dienste. Gehe in den IIS an die Portbindung 443 und erstelle einen zusätzlichen Eintrag für https auf den Hostname und wähle
des Zertifikat für die externe Domäne aus.
Dann wird alle Hostnamen (*) an exchange.domain.local "geschickt" und Hostname exchange.domain.de über das "echte" Zertifikat.
Hat jemand eine Erklärung/Idee
Danke schön, der Lenhart
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 317266
Url: https://administrator.de/contentid/317266
Printed on: April 16, 2024 at 09:04 o'clock
6 Comments
Latest comment
Moin,
Du hinterlegst in den Veröffentlichungen für den Exchange (OWA, ECP) auf dem WAP einfach das Zertifikat für exchange.domain.de und gut ist. Was evtl. noch notwendig ist, dass du das Zertifikat der Stammzertifizierungsstelle welches das Zertifikat für exchange.domain.local ausgestellt hat, noch auf dem WAP installiert werden muss.
Gruß,
Dani
Es gibt ein Proxy, WAF (ist so gewünscht, trotz Sicherheitsbedenken).
WAF ist ein Reverse Proxy (http und https) und wird so auch sicherlich ein paar Milllionen mal eingesetzt. Höchstens man konfiguriert das Ding nicht anständig, dann hätte ich auch Sicherheitsbedenken. Aber wenn als im Detail konfiguriert, dokumentiert und gehärtet ist, sehe ich da keine Probleme.Oder ist das System denn so "schlau" und erkennt anhand des https Requests, welche Domäne aufgerufen wird und
würde dass zur Domäne passende Zertifikat verwenden?Du hinterlegst in den Veröffentlichungen für den Exchange (OWA, ECP) auf dem WAP einfach das Zertifikat für exchange.domain.de und gut ist. Was evtl. noch notwendig ist, dass du das Zertifikat der Stammzertifizierungsstelle welches das Zertifikat für exchange.domain.local ausgestellt hat, noch auf dem WAP installiert werden muss.
Gruß,
Dani
1
Hallo,
Was sind denn deine Sicherheitsbedenken?
Gruß,
Peter
Was sind denn deine Sicherheitsbedenken?
Gruß,
Peter
Wie Dani schon richtig geschrieben hat, google mal nach "Exchange Split-DNS"..
Gruß,
Christoph
Gruß,
Christoph
1
Jupp, mein Fehler KEIN WAF. Sorry. ;-(
Hallo,
kleine Korrektur: KEIN WAF sollte es heißen
Genau, das zur Domäne (lokal!) passende Zertifikat wurde verwendet. Ein weiteres externes gibt es
nicht.
Deshlab müsste ich auch dem Exchange (und nicht WAP) noch zusätzlich exchange.domain.de
einrichten und an die Domäne binden. Ich meine, das sollte klappen.
kleine Korrektur: KEIN WAF sollte es heißen
Genau, das zur Domäne (lokal!) passende Zertifikat wurde verwendet. Ein weiteres externes gibt es
nicht.
Deshlab müsste ich auch dem Exchange (und nicht WAP) noch zusätzlich exchange.domain.de
einrichten und an die Domäne binden. Ich meine, das sollte klappen.
Deshlab müsste ich auch dem Exchange (und nicht WAP) noch zusätzlich exchange.domain.de
einrichten und an die Domäne binden. Ich meine, das sollte klappen.Wenn du auf SNI im IIS zurückgreifst, kannst du zwei Bindungen auf Port 443 mit unterschiedlichen DNS-Namen konfigurieren. Das könnte klappen... hab ich noch nie so gemacht. Wir setzen immer ein Reverse Proxy davor.
Gruß,Dani
1