Extended Protection mit internen Zertifikaten
Im Februar 2024 hat Microsoft als Reaktion auf CVE-2024-21410 Betrachtung zum Schutz gegen Man in the Middle Attacken über NTLM mit dem Exchange Updates die Funktion Exchange Extended Protection per Default aktiviert. Technisch wird dabei IIS Extended Protection aktiviert und das Aufbrechen der TLS-Verbindung durch eine Firewall oder einen Reverse-Proxy nur unter bestimmten Voraussetzungen erlaubt. Das kann eine Herausforderung sein, wenn Sie eine eigene PKI und private DNS-Domains mit Exchange intern nutzen.
Ausgangssituation
Sehr viele Firmen mit eine lokalen Exchange Server haben in der Vergangenheit folgende Konfiguration aufgebaut:
- Interne DNS-Namen
Wer kein Split-DNS nutzt, hat intern einen anderen DNS-Domainname und damit hat auch der Exchange Server einen FQDN, den sie im Internet nicht nutzen können. - Reverse-Proxy/Firewall/Loadbalancer
Die Lösung bestand darin, aus dem Internet den TLS-Zugriff auf ein System zu leiten, welches passend zum externen Namen auch ein von einer allgemein vertrauenswürdigen Zertifizierungsstelle Zertifikat vorweisen kann. Das System hat die TLS-Verbindung geöffnet, die URLs und teilweise auch Inhalte auf Malware überprüft, ggfls. eine Preauthentication angefordert und dann die Verbindung zum internen Zielserver einfach neu verschlüsselt. - InternalURL/ExternalURL
Exchange hat so eine Konfiguration mit unterschiedlichen Servernamen aus dem internen Netzwerk und dem Internet unterstützt.
Das Problem mit diesem Setup sind zwei unterschiedliche Zertifikate, die mit IIS Extended Protection/Exchange Extended Protection nicht mehr funktionieren. Sobald diese Funktion aktiv ist, bezieht der Exchange Server auch das von ihm genutzte interne Zertifikat in die Challenge/Response-Authentifizierung bei NTLM mit ein und da der Client das öffentliche Zertifikat ein anderes Schlüsselmaterial nutzt, kommt keine erfolgreiche Anmeldung zustande.
Lösung mit Reverse-NAT
Sie könnten natürlich auf die TLS-Inspection verzichten und auch ein Loadbalancer könnte einfach TCP-Connections als Layer-4-Loadsbalancer verteilen und die öffentliche IP-Adresse können Sie mittels Reverse-NAT/NAT auch auf eine interne private IP-Adresse umsetzen.
Dann wäre zwar Exchange Extended Protection möglich aber sie verlieren sehr viele Schutzfunktionen, z.B. eine Preauthentication oder URL-Inspektion. Stellen Sie sich einfach mal vor, auf ihrem Exchange Webserver hätte einer 3rd Party Software noch ein weiteres virtuelle Verzeichnis angelegt. Dieses wäre dann auch direkt von extern erreichbar. Schon aus Sicherheitsüberlegungen sollten Sie nicht einen Webserver komplett sondern nur die wirklich notwendigen Verzeichnisse und URLs veröffentlichen, um Angriffe abzuwehren oder auch erst zu erkennen.
So eine Änderung hat aber noch einen zweiten großen Nachteil. In meinem Beispiel werde ich für den internen FQDN des Servers "ex01.msxfaq.local" natürlich ein Zertifikat einer öffentliche Zertifizierungsstelle bekommen. Selbst wenn, dann wird es durch SAN-Zertifikate mit den vielen Namen deutlich teurer und aufwändiger.
Wenn nun aber ein interne Client auf den internen privaten Namen zugreift und der Name nicht im Zertifikat vorhanden ist, dann kommt die Verbindung einfach nicht zustande. Anwender sehen "Zertifikatswarnung", die Sie besser nicht einfach ignorieren. Hier mag es vielleicht OK sein, aber es sollte nie zur Gewohnheit werden, weil Sie damit das gesamte System "TLS" torpedieren. Morgen klickt der Anwender die Warnung beim Zugriff auf eine Banking-Seite o.ä. ab. Das sollten Sie nicht fördern.
Zwei Zertifikate mit SNI
Die Lösung ist relativ einfach, auch wenn Microsoft diese so meines Wissens noch nicht deutlich beschrieben hat und sie auf keinen Fall die Exchange PowerShell dazu verwenden dürfen. Der Windows WebServer (IIS) unterstützt schon lange die Funktion Server Name Indication (SNI) und die meisten Clients ebenfalls. Ein Client sendet beim Verbindungsaufbau mit dem ersten Paket auch den gewünschten Hostnamen mit. So können z.B. große Provider viele unterschiedliche Instanzen eines Service auf der gleichen IP-Adresse und Port 443 betreiben und müssen nicht pro Webseite eine eigene kostbare öffentliche IP-Adresse bereitstellen.
Zuerst müssen sie nun das öffentliche Zertifikat samt privaten Schlüssel im Computerstore des Exchange Servers importieren. Danach konfigurieren Sie im IIS-Manager die Bindungen der Default Webseite und addieren einfach den gewünschten Namen, das dazu passende Zertifikat und aktivieren die Checkbox bei "SNI".
Das "SNI"-Feld erscheint natürlich nur, wenn Sie als "Type=https" ausgewählt haben. Bei unverschlüsselten Verbindungen per HTTP gibt es zwar auch einen Hostheader aber kein Zertifikat.
Nach der Speicherung der neuen Bindung sollte in der Übersicht ein weiterer Eintrag erscheinen:
Leider zeigt die Tabelle nicht den Namen des Zertifikats mit an. Bei jeder neuen eingehenden TLS-Verbindung nutzt Exchange nun den per SNI gemeldeten Namen, um das passende Zertifikat zu verwenden. Mit dem kleinen Kniff können Sie sowohl das bisher genutzte interne Zertifikat unverändert weiter verwenden, welches Exchange mit "Enable-ExchangeCertificate" gebunden hat.
Das "owa.msxfaq.de"-Zertifikat hat hier kein "W", weil es nicht an als Default-Zertifikat an die Default Webseite gebunden ist.
Achtung mit Enable-ExchangeCertificate.
Wenn Sie per Exchange PowerShell das öffentliche Zertifikat
aktivieren, dann ersetzt es das "Default Certificate".
Prüfen Sie z.B. mit einem Browser den Zugriff auf den internen Namen, damit weiterhin das richtige Zertifikat erscheint.
Dies ist auch für die Kommunikation zwischen Exchange Servern, Stichwort "FrontendProxy->Backend"-Kommunikation wichtig. Wenn aber ein Client eine Verbindung über den dem öffentlichen Namen zum Exchange Server herstellt, dann sieht er das passende Zertifikat. Damit haben wir dann zwei Optionen, wie wir Exchange mit beiden Namen veröffentlichen können:
Sie können nun natürlich weiter ihren Exchange Server direkt per NAT aus dem Internet erreichbar machen. Das ist aber eher etwas für sehr kleine Firmen und hier würde ich dann eher eine Migration zu einem Exchange Hoster, z.B. Microsoft 365, empfehlen. Wenn Sie aber selbst einen Reverse Proxy oder Firewall mit TLS-Inspection, Preauth, DoS-Abwehr etc. einsetzen, dann können Sie nun die eingehende TLS-Verbindung aus dem Internet wie früher auf dem Firewall-System terminieren, die Inhalte untersuchen und dann die Verbindung zum internen Exchange Server neu aufbauen. Hier müssen Sie dann natürlich sicherstellen, dass das "öffentliche Zertifikat" auf dem Exchange Server mit dem von extern sichtbare Zertifikat identisch ist. Es muss wirklich das gleich Zertifikat mit dem gleichen Hashwert, Name, Aussteller, Gültigkeit etc. sein, damit die NTLM-Anmeldung per IIS Extended Protection auch tatsächlich funktioniert.
Über diesen Weg kann ich dem Exchange Server sogar weitere Zertifikat mit unterschiedlichen Hostnamen hinterlegen ohne gleich das "Default Web Server Zertifikat umzustellen. Das sollte ich nämlich zumindest auf der "Exchange Backend"-Webseite nicht aufpassen. Die Exchange Server nehmen nämlich Clientverbindungen per HTTP/HTTPS auf der Default Webseite an um dann aber nach der Authentifizierung die Requests zu dem passenden Backend Server zu leiten, auf dem die aktive Datenbank zum angesprochenen Postfach ist. Dazu nutze Exchange immer der FQDN des Zielservers und das ist auch mal ein "ex01.msxfaq.local" o.ä. zu dessen Namen es kein öffentliches Zertifikat geben kann. Zumindest die "Exchange Backend"-Webseite darf daher keine Änderungen an den Zertifikaten erfahren.
Siehe dazu auch Exchange Zertifikat Insights.
