Exchange 2010: Zertifikate von Let’s Encrypt nutzen (Teil 1)

Zertifikate von Let’s Encrypt werden immer beliebter, ist ja auch kaum verwunderlich, denn die Zertifikate sind kostenlos und es gibt einfache Clients um die Zertifikate zu bekommen. Let’s Encrypt Zertifikate sind zwar nur 3 Monate lang gültig, aber die verfügbaren Clients übernehmen das Erneuern der Zertifikate.

Exchange 2016 lässt sich sogar mit einem kleinen PowerShell Script völlig automatisieren. Im Prinzip ist dieses auch mit Exchange 2010 machbar, was bereits einige angefragt haben und das Script sogar selbst abgewandelt haben. Damit später aber keine Zertifikatswarnungen auftauchen ist ein wenig Vorarbeit nötig.

Ich habe daher eine kleine Demoumgebung bestehend aus einem Domain Controller und einem Exchange 2010 Server aufgebaut um eine der möglichen Konfigurationen zu veranschaulichen.

Das Active Directory hört auf den Namen frankysweb.local. Die Benutzer verwenden die E-Mail Adressen @frankysweb.org. Eine Umgebung dieser Art dürfte man noch recht häufig vorfinden, daher verwende ich diese Umgebung auch für dieses HowTo.

Der Domain Controller hört auch den Namen dc.frankysweb.local und der Exchange 2010 Server auf den Namen ex2010.frankysweb.local.

Für Exchange 2010 gilt es als Best-Practise interne und externe Zugriffspunkte von einander zu trennen. Diese kleine Umgebung wird daher die folgenden Zugriffspunkte nutzen:

• outlook.int.frankysweb.org (Interner Zugriffspunkt)
• outlook.frankysweb.org (Externer Zugriffspunkt)
• autodiscover.frankysweb.org (Autodiscover Intern sowie Extern)

Der Exchange Server ist via Router direkt mit dem Internet verbunden:

Am Router sind entsprechende Port Forward Regeln eingerichtet. Port 80,443 und 25 werden direkt auf den Exchange Server weitergeleitet. Port 25 ist für diesen Artikel nicht relevant. Port 80 und 443 sind Pflicht.

Hinweis: Das HowTo besteht aus zwei Artikeln, bitte erst beide Artikel abwarten. Siehe “Nächste Schritte” am Ende des Artikels. Wichtig ist ebenfalls der Abschnitt “Exchange CAS Array”!

DNS

Das DNS auf meinem Domain Controller kennt nach der Testinstallation nur die Zone “frankysweb.local”, in dieser Zone gibt es auch den Host-A Eintrag des Exchange Servers mit dem Namen EX2010:

In dieser Testumgebung habe ich noch keine Konfiguration vorgenommen, was zur Folge hat, das Outlook nun eine Verbindung zum Exchange Server mit dem Namen “EX2010.frankysweb.local” aufbaut. Dies ist auch in der Outlook Verbindungsübersicht zu sehen:

Solange der DNS-Name “EX2010.frankysweb.local” auf dem Zertifikat für Exchange vorhanden ist, stellt dies auch kein Problem dar. Let’s Encrypt, sowie auch alle anderen CAs stellen aber keine Zertifikate für private TLDs aus (.local, .intern, etc). Mit einer eigenen CA kann man solche Zertifikate ausstellen, mit öffentlichen CAs funktioniert dieses nicht, auch weil im Falle von Let’s Encrypt der interne Name nicht verifiziert werden kann.

Die Verbindung muss also über einen öffentlich gültigen DNS-Namen hergestellt werden. Um dies zu erreichen und gleichzeitig die Exchange 2010 Best-Practise “Trenne interne und externe Zugriffpunkte” umzusetzen, werden zunächst am internen DNS zwei neue Zonen angelegt. Hier wird also ganz klassisch DNS Split Brain genutzt.

Die Zone “int.frankysweb.org” bekommt nur einen HOST-A Eintrag mit der internen IP des Exchange Servers. Der DNS-Name outlook.int.frankysweb.org wird dann später für die internen Zugriffe verwendet:

Die Zone “frankysweb.org” bekommt zwei HOST-A Einträge mit den Namen “outlook” und “autodiscover”. Diese beiden Einträge werden später auch beim Hoster der öffentlichen DNS-Zone angelegt und werden für Outlook Anywhere und Autodiscover verwendet:

Für das Let’s Encrypt Zertifikat ergeben sich somit später 3 DNS-Namen:

• outlook.int.frankysweb.org (Interner Zugriffspunkt)
• outlook.frankysweb.org (Externer Zugriffspunkt)
• autodiscover.frankysweb.org (Autodiscover Intern sowie Extern)

Dazu später mehr.

Exchange CAS-Array

Das Exchange 2010 CAS-Array ist etwas tükisch. In der Standardkonfiguration ist kein CAS-Array konfiguriert, was zur Folge hat das alle Outlook Verbindungen zum lokalen FQDN des Exchange Servers aufgebaut werden. In Outlook Verbindungsstatus wird dies deutlich:

Mit dem CAS-Array ist es möglich, den FQDN des Exchange Servers zu ändern, dies ist Voraussetzung wenn eine hochverfügbare Exchange Umgebung konfiguriert wird, aber eben auch um den lokalen Servernamen eines einzelnen Exchange Servers loszuwerden.

Das gemeine am CAS-Array ist folgendes: Wenn es bereits Outlook Profile gibt die den lokalen FQDN verwenden und das CAS-Array nachträglich eingerichtet wird, ändert sich das Outlook Profil nicht. Das heißt konkret, bereits eingerichtete Outlooks werden nicht auf den neuen FQDN des CAS-Arrays verwiesen, sondern behalten den alten FQDN bei. Hier hilft nur nach der Einrichtung des CAS-Arrays auch das Outlook Profil neu zu erstellen, oder es mit mit dem Tool “RichProfile” nachträglich zu ändern.

Um ein das CAS-Array zu erzeugen und den FQDN für den Zugriff zu ändern wir der folgende Befehl auf der Exchange Shell ausgeführt:

New-ClientAccessArray -Name CASArray -Fqdn outlook.int.frankysweb.org -Site Default-First-Site-Name

Das CAS-Array ist nun angelegt und muss dann den Mailbox Datenbanken zugewiesen werden:

Set-MailboxDatabase MBDB1 -RpcClientAccessServer outlook.int.frankysweb.org

Nachdem das vorhandene Outlook Profil neu erstellt wurde, oder das Profil mit dem oben genannten Tool angepasst wurde, läuft nun die Verbindung gegen “outlook.int.frankysweb.org”

Die restlichen Exchange URLs können jetzt ebenfalls angepasst werden.

Exchange URLs

Damit später keine Zertifikatswarnungen auftreten und Autodiscover einwandfrei funktioniert, können nun auch die restlichen URLs für die jeweiligen Exchange Dienste angepasst werden.

Zunächst wird die Autodiscover URL auf “autodiscover.frankysweb.org” verändert:

Get-ClientAccessServer | Set-ClientAccessServer -AutoDiscoverServiceInternalUri https://autodiscover.frankysweb.org/Autodiscover/Autodiscover.xml

Dann kann Outlook Anywhere eingeschaltet werden, oder bei bereits eingeschalteten Outlook Anywhere der Hostname auf “outlook.frankysweb.org” geändert werden. Für Outlook Anywhere muss nur der externe Hostname angegeben werden, der interne Name ist der FQDN des CAS-Arrays, welches vorher schon konfiguriert wurde:

Die virtuellen Verzeichnisse werden nun mit den entsprechenden URLs konfiguriert. interner FQDN ist outlook.int.frankysweb.org und externer FQDN ist outlook.frankysweb.org, daraus ergeben sich dann die URLs. Hier im Beispiel für OWA:

Gleiches gilt für ECP:

Und hier für ActiveSync:

Und auch für das OAB:

Es gibt noch ein weiteres Verzeichnis welches nicht direkt via Exchange Konsole konfiguriert werden kann, sondern nur mit der Exchange Shell. Um die EWS URL zu ändern, kann der folgende Befehl verwendet werden:

Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -InternalUrl https://outlook.int.frankysweb.org/EWS/Exchange.asmx -ExternalUrl https://outlook.frankysweb.org/EWS/Exchange.asmx

Nachdem alle URLs angepasst wurden, wird der IIS einmal neu gestartet:

iisreset

Der Outlook Autodiscover Test sollte jetzt nur noch die entsprechend konfigurierten URLs für interne und externe Zugriffspunkte verteilen. der interne FQDN “EX2010.frankysweb.local” darf nicht mehr auftauchen:

Nächste Schritte

Ohne ein gültiges Zertifikat kommt es jetzt zu Zertifikatswarnungen. Im zweiten Teil wird dann das externe DNS angepasst und das Let’s Encrypt Zertifikat konfiguriert.