12
Fehlermeldung in einem Exchange-Server wenn man über einen Reverse-Proxy darauf zugreift
Hallo,
ich habe bei einem Kunden einen Exchange-Server 2013 am laufen, welcher an sich tadellos funktioniert.
Darauf zugegriffen wird über Oultook 365 und einige Handys, welche per Active-Sync angebunden sind.
Nun wollten wir eine Andere Anwendung ebenfalls per 443 erreichbar machen und haben daher den Versuch unternommen, einen Reverse Proxy bei dem Kunden einzusetzen.
Diesen haben wir mit einem Apache2 Webserver auf einem Ubuntu 20 aufgesetzt.
Leider fuktioniert jedoch der Zugriff über den Reverse Proxy auf den Exchange-Server nicht, da wir immer nur die Meldung im Anhang zurück bekommen, welche ich unten angefügt habe.
Auf die andere Anwendung können wir jedoch über den Reverse-Proxy einwandfrei zugreifen, daher denke ich nicht, dass es an dem Reverse-Proxy liegt.
Aufgefallen ist uns jedoch noch im Exchange-Server-Log noch folgendes, die Fehlermeldung kommt jedoch immer, egal ob mit oder ohne Reverse-Proxy. Sie scheint sich nur ohne den Reverse Proxy nicht bemerkbar zu machen:
Eine TLS 1.2-Verbindungsanforderung wurde von einer Remoteclientanwendung übermittelt, jedoch werden keine der Verschlüsselungssammlungen, die von der Clientanwendung unterstützt werden, vom Server unterstützt. Fehler bei der SSL-Verbindungsanforderung.
Quelle Schannel EventID 36874
Es wurde eine schwerwiegende Warnung generiert und an den Remoteendpunkt gesendet. Dies kann dazu führen, dass die Verbindung beendet wird. Die schwerwiegende Warnung hat folgenden für das TLS-Protokoll definierten Code: 40. Der Windows-SChannel-Fehlerstatus lautet: 1205.
Quelle Schannel EventID 36888
Es wurde eine schwerwiegende Warnung vom Remoteendpunkt empfangen. Die schwerwiegende Warnung hat folgenden für das TLS-Protokoll definierten Code: 46.
Quelle Schannel ID 36887
Jedoch bin ich mir nicht sicher, ob das tatsächlich der Grund für das Verbindungsproblem ist, da die Meldungen ja auch ohne den Reverse Proxy dazwischen erscheinen und dann ja alles Funktioniert.
Der Exchange-Server ist auf dem aktuellsten Patchlevel Stand 19.03.2021.
Ich würde mich sehr freuen, wenn mir jemand hierbei helfen könnte und Ideen dazu hat.
Vielen Dank im Vorraus
ich habe bei einem Kunden einen Exchange-Server 2013 am laufen, welcher an sich tadellos funktioniert.
Darauf zugegriffen wird über Oultook 365 und einige Handys, welche per Active-Sync angebunden sind.
Nun wollten wir eine Andere Anwendung ebenfalls per 443 erreichbar machen und haben daher den Versuch unternommen, einen Reverse Proxy bei dem Kunden einzusetzen.
Diesen haben wir mit einem Apache2 Webserver auf einem Ubuntu 20 aufgesetzt.
Leider fuktioniert jedoch der Zugriff über den Reverse Proxy auf den Exchange-Server nicht, da wir immer nur die Meldung im Anhang zurück bekommen, welche ich unten angefügt habe.
Auf die andere Anwendung können wir jedoch über den Reverse-Proxy einwandfrei zugreifen, daher denke ich nicht, dass es an dem Reverse-Proxy liegt.
Aufgefallen ist uns jedoch noch im Exchange-Server-Log noch folgendes, die Fehlermeldung kommt jedoch immer, egal ob mit oder ohne Reverse-Proxy. Sie scheint sich nur ohne den Reverse Proxy nicht bemerkbar zu machen:
Eine TLS 1.2-Verbindungsanforderung wurde von einer Remoteclientanwendung übermittelt, jedoch werden keine der Verschlüsselungssammlungen, die von der Clientanwendung unterstützt werden, vom Server unterstützt. Fehler bei der SSL-Verbindungsanforderung.
Quelle Schannel EventID 36874
Es wurde eine schwerwiegende Warnung generiert und an den Remoteendpunkt gesendet. Dies kann dazu führen, dass die Verbindung beendet wird. Die schwerwiegende Warnung hat folgenden für das TLS-Protokoll definierten Code: 40. Der Windows-SChannel-Fehlerstatus lautet: 1205.
Quelle Schannel EventID 36888
Es wurde eine schwerwiegende Warnung vom Remoteendpunkt empfangen. Die schwerwiegende Warnung hat folgenden für das TLS-Protokoll definierten Code: 46.
Quelle Schannel ID 36887
Jedoch bin ich mir nicht sicher, ob das tatsächlich der Grund für das Verbindungsproblem ist, da die Meldungen ja auch ohne den Reverse Proxy dazwischen erscheinen und dann ja alles Funktioniert.
Der Exchange-Server ist auf dem aktuellsten Patchlevel Stand 19.03.2021.
Ich würde mich sehr freuen, wenn mir jemand hierbei helfen könnte und Ideen dazu hat.
Vielen Dank im Vorraus
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 665090
Url: https://administrator.de/contentid/665090
Ausgedruckt am: 22.11.2024 um 15:11 Uhr
12 Kommentare
Neuester Kommentar
Ich würde gucken, welchen Verschlüsselungstyp (TLS-Version) der Exchange einsetzt und diese dann, wenn auch erwzungen, am Server einstellen.
Das Zertifikat das Exchange-Servers ist dem Reserve-Proxy bekannt? Notfalls manuell einbinden.
VG
bitnarrator
PS: Mach bei deinem Starface-Proxy aufch mal SSL rein
Kommt besser...
Das Zertifikat das Exchange-Servers ist dem Reserve-Proxy bekannt? Notfalls manuell einbinden.
VG
bitnarrator
PS: Mach bei deinem Starface-Proxy aufch mal SSL rein
Kommt besser...
Der Exchange-Server unterstützt die TLS-Versionen 1.1 und 1.2.
Das Zertifikat der CA ist dem Reverse-Proxy nicht bekannt, hier hätte ich jedoch den Parametzer gesetzt, dass er diese Ignoriert.
Die Starface ist die 2. Anwendung, welche dann auch über den Proxy laufen soll, hierzu muss ich ihn jedoch zuerst aktivieren dürfen, was ich momentan nicht kann, da dann der Exchange ja nicht mehr ansprechbar ist.
Vielen dank übrigens für den Hinweis, die Kundendomain im Bild hab ich übersehen und jetzt noch geschwärzt.
Wie kann ich im Apache fixen, dass dieser nur noch 1.2 nutzt und wieso ist dies bei dem Kunden notwendig.
Bei den letzten Reverse-Proxys vor Exchange-Servern war dies nicht nowendig?
Daher hätte ich eher auf einen Fehler im Exchange getippt.
Das Zertifikat der CA ist dem Reverse-Proxy nicht bekannt, hier hätte ich jedoch den Parametzer gesetzt, dass er diese Ignoriert.
Die Starface ist die 2. Anwendung, welche dann auch über den Proxy laufen soll, hierzu muss ich ihn jedoch zuerst aktivieren dürfen, was ich momentan nicht kann, da dann der Exchange ja nicht mehr ansprechbar ist.
Vielen dank übrigens für den Hinweis, die Kundendomain im Bild hab ich übersehen und jetzt noch geschwärzt.
Wie kann ich im Apache fixen, dass dieser nur noch 1.2 nutzt und wieso ist dies bei dem Kunden notwendig.
Bei den letzten Reverse-Proxys vor Exchange-Servern war dies nicht nowendig?
Daher hätte ich eher auf einen Fehler im Exchange getippt.
Hallo,
doppelte Verschlüsselung ist immer etwas unglücklich und mit erheblichen Performanceeinbrüchen verbunden.
Ich würde den Exchanger vom Proxy aus direkt auf Port 80 ansprechen (wenn der 2016 das noch kann).
Gruß,
Jörg
doppelte Verschlüsselung ist immer etwas unglücklich und mit erheblichen Performanceeinbrüchen verbunden.
Ich würde den Exchanger vom Proxy aus direkt auf Port 80 ansprechen (wenn der 2016 das noch kann).
Gruß,
Jörg
Hey,
ich habe die Erfahrung gemacht, dass hier ein Nginx deutlich einfacher zu händeln ist.
Nginx und keepalived auf zwei Server installieren, und dann nachher den Upstream per Servername zu unterschiedlichen Zielen schicken (Exchange und andere Webseiten/diensten ) Fertig ist das Cluster.
je nach Aufkommen kannst du den Ubuntu dann mit 1 kern und 1 GB Ram laufen lassen.
Es gibt viele Anleitungen, mit denen auch die Verschlüsselung vom Exchange gut funktioniert.
Über Geschwindigkeitsproblemen kann ich nicht klagen.
ist nur ein Vorschlag von mir. nicht dass gleich zerhackt werde xD.
Gruß
Vans66
ich habe die Erfahrung gemacht, dass hier ein Nginx deutlich einfacher zu händeln ist.
Nginx und keepalived auf zwei Server installieren, und dann nachher den Upstream per Servername zu unterschiedlichen Zielen schicken (Exchange und andere Webseiten/diensten ) Fertig ist das Cluster.
je nach Aufkommen kannst du den Ubuntu dann mit 1 kern und 1 GB Ram laufen lassen.
Es gibt viele Anleitungen, mit denen auch die Verschlüsselung vom Exchange gut funktioniert.
Über Geschwindigkeitsproblemen kann ich nicht klagen.
ist nur ein Vorschlag von mir. nicht dass gleich zerhackt werde xD.
Gruß
Vans66
Hallo,
auf jedem Fall würde ich erst einmal die CA, die den Exchanger zertifiziert hat, auf dem Proxyserver etablieren.
Gruß,
Jörg
auf jedem Fall würde ich erst einmal die CA, die den Exchanger zertifiziert hat, auf dem Proxyserver etablieren.
Gruß,
Jörg
Moin,
Schau dir doch die SSL Konfiguration des Apache2 an. Du wirst feststellen, dass die Entwickler nur noch sehr starke Cipher Suites zu lässt. Wenn du nicht gerade Windows Server 2019 einsetzt, wird damit die Kommunikation mit dieser Konfiguration nie zu stande kommen. Das liegt einfach daran, dass Microsoft innerhalb einer Windows Server Version noch nie über ein Updates die Kryptobibliothek aktualisiert hat.
Kurz um: Passe die Konfiguration für SSL des Apache2 an und die Verbindung klappt.
Gruß,
Dani
Der Exchange-Server unterstützt die TLS-Versionen 1.1 und 1.2
das ist aber nur die halbe Miete. Neben den SSL Prokolle spielen natürlich auch die Cipher Suites eine Rolle. Erst dann wird die Verbindung zwischen IIS und Apache2 funktionieren. Wobei der IIS keine eigene Bibliothek für Kryptografie mitbringt sondern auf die APIs von Windows Server zurückgreift.Schau dir doch die SSL Konfiguration des Apache2 an. Du wirst feststellen, dass die Entwickler nur noch sehr starke Cipher Suites zu lässt. Wenn du nicht gerade Windows Server 2019 einsetzt, wird damit die Kommunikation mit dieser Konfiguration nie zu stande kommen. Das liegt einfach daran, dass Microsoft innerhalb einer Windows Server Version noch nie über ein Updates die Kryptobibliothek aktualisiert hat.
Kurz um: Passe die Konfiguration für SSL des Apache2 an und die Verbindung klappt.
Das Zertifikat der CA ist dem Reverse-Proxy nicht bekannt,
Wie hast du das unterbunden? Kann in diesen Fall nur ein Self-Signed Zertifikat sein. Was ich damit automatisch andere Probleme zu Tage fördert. Bei den letzten Reverse-Proxys vor Exchange-Servern war dies nicht nowendig?
Andere Betriebssysteme, andere Apache2 Version, etc?! Daher hätte ich eher auf einen Fehler im Exchange getippt.
Es ist kein Fehler der Anwendung, es ist ein Fehler des Admins. Gruß,
Dani
Der Exchange-Server unterstützt die TLS-Versionen 1.1 und 1.2
das ist aber nur die halbe Miete. Neben den SSL Prokolle spielen natürlich auch die Cipher Suites eine Rolle. Erst dann wird die Verbindung zwischen IIS und Apache2 funktionieren. Wobei der IIS keine eigene Bibliothek für Kryptografie mitbringt sondern auf die APIs von Windows Server zurückgreift.Schau dir doch die SSL Konfiguration des Apache2 an. Du wirst feststellen, dass die Entwickler nur noch sehr starke Cipher Suites zu lässt. Wenn du nicht gerade Windows Server 2019 einsetzt, wird damit die Kommunikation mit dieser Konfiguration nie zu stande kommen. Das liegt einfach daran, dass Microsoft innerhalb einer Windows Server Version noch nie über ein Updates die Kryptobibliothek aktualisiert hat.
Kurz um: Passe die Konfiguration für SSL des Apache2 an und die Verbindung klappt.
OK, wenn es tatsächlich am Apache liegt tue ich das gerne, kannst du mir hier auch sagen, was ich genau anpassen muss?
Wundert mich nur, das ich das Identisch konfigurierte Reverse-Proxy bisher immer funktionierten.
Habe Reverse-Proxys inzwischen vor Exchange 2013, 2016 und 2019 laufen, die funktionieren alle Einwandfrei.
Der einzige Unterschied ist, dass bei den Exchange-Servern die komische Fehlermeldung nicht im Log zu finden ist.
Zu dieser Fehlermeldung evtl. auch eine Idee
Das Zertifikat der CA ist dem Reverse-Proxy nicht bekannt,
Wie hast du das unterbunden? Kann in diesen Fall nur ein Self-Signed Zertifikat sein. Was ich damit automatisch andere Probleme zu Tage fördert.Ich habe in die Konfig des Proxys der Domains diese Parameter gesetzt:
SSLProxyEngine On
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off
Bei den letzten Reverse-Proxys vor Exchange-Servern war dies nicht notwendig?
Andere Betriebssysteme, andere Apache2 Version, etc?!Die anderen Reverse Proxys laufen vor Exchange 2013, 2016, 2019 welche als Betriebssystem Windows Server 2012R2, 2016 und 2019 haben.
Dieser Hat ebenfalls Windows Server 2012R2 und ist ein Exchange 2013.
Sprich ja, ich habe auch schon Reverse-Proxys vor Exchange-Servern mit der gleichen Version und mit dem gleichen Betriebssystem laufen.
Daher hätte ich eher auf einen Fehler im Exchange getippt.
Es ist kein Fehler der Anwendung, es ist ein Fehler des Admins. Wird sich zeigen, will ich aber nicht verneinen.
Man lernt in unserem Beruf ja nie aus.
Ich muss jetzt nur herausfinden, wo das Problem liegt.
Wobei das Problem auch evtl. ich bin, der ich den Exchange Administriere.
ich hab nun auch mal getestet, was passiert, wenn ich einen anderen Reverse-Proxy, welcher vor einem anderen Exchange 2013 läuft auf diesen Exchange umbiege. ---> hier bekomme ich das gleiche Fehlerbild
Wenn ich diesen Reverse-Proxy auf den anderen Exchange 2013 umbiege funktioniert der Reverse-Proxy.
Scheint wohl doch was mit dem Exchange zu tun zu haben.
Für weitere Hilfe bin ich jederzeit empfänglich.
Moin,
ich war leider die letzte Woche abwesend. Hast du eine Lösung inzwischen gefunden?
Gruß,
Dani
ich war leider die letzte Woche abwesend. Hast du eine Lösung inzwischen gefunden?
Gruß,
Dani
Moin,
leider nein.
Jedoch kann ich inzwischen sagen, dass der Fehler auch in der Ereignisanzeige zu sehen ist, wenn man nicht über den Reverse-Proxy auf den Exchange zugreift.
Nur wirkt sich der Fehler wohl dann nicht aus. Nur wenn man über den Reverse-Proxy kommt, kann dieser die SSL-Aushandlung nicht durchführen. (so Interpretiere ich den Fehler)
Daher wäre Step 1 wohl, den Fehler zu bearbeiten, welcher sich in der Ereignisanzeige des Exchange-Servers zeigt und dann weiter zu machen.
Für jegliche Vorschläge hierzu, wäre ich sehr dankbar, da ich leider so im Internet noch nichts brauchbares dazu gefunden habe.
leider nein.
Jedoch kann ich inzwischen sagen, dass der Fehler auch in der Ereignisanzeige zu sehen ist, wenn man nicht über den Reverse-Proxy auf den Exchange zugreift.
Nur wirkt sich der Fehler wohl dann nicht aus. Nur wenn man über den Reverse-Proxy kommt, kann dieser die SSL-Aushandlung nicht durchführen. (so Interpretiere ich den Fehler)
Daher wäre Step 1 wohl, den Fehler zu bearbeiten, welcher sich in der Ereignisanzeige des Exchange-Servers zeigt und dann weiter zu machen.
Für jegliche Vorschläge hierzu, wäre ich sehr dankbar, da ich leider so im Internet noch nichts brauchbares dazu gefunden habe.
Hey ,
Hast du diese Anleitung schon probiert ?
Wenn die funktioniert, würde ich aber die ECP Regel auskommentiern
https://znil.net/index.php/Apache2_als_Reverse_Proxy_f%C3%BCr_Exchange_2 ...
Hast du diese Anleitung schon probiert ?
Wenn die funktioniert, würde ich aber die ECP Regel auskommentiern
https://znil.net/index.php/Apache2_als_Reverse_Proxy_f%C3%BCr_Exchange_2 ...
Ja, die habe ich schon ausprobiert.
Ich habe eine funktionsfähige nginx konfig. Die könnte ich dir teilen, wenn du den nginx nutzen möchtest .
Gruß vans66
Gruß vans66
