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:

Exchange 2010 Let's Encrypt Zertifikate

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:

image

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:

image

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:

image

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:

image

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:

image

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

image

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

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

image

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”

image

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

image

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:

image

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:

image

Gleiches gilt für ECP:

image

Und hier für ActiveSync:

image

Und auch für das OAB:

image

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

image

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

iisreset

image

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:

image

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.

11 Kommentare zu “Exchange 2010: Zertifikate von Let’s Encrypt nutzen (Teil 1)”

  1. Hallo Franky

    Ich lese hier schon länger mit und hätte eine kurze Frage, geht aber um einen DC 2016 und einen EX 2016
    Wir setzten hier im Moment noch eigenen Zertifikate ein mit einer CA auf dem DC.
    OWA und ActiveSync gehen wenn ich das Zertifikat auf den Clients installieren.
    Jetzt die Frage, muss ich was beachten wenn ich auf Let’s Crypt wechseln will mit deinem Script, oder muss ich es einfach nur ausführen und er macht alles von alleine?

    Und hier muss gleich die ganze Seite mal loben, hat mir schon viel geholfen und ist sehr sehr informativ. Einfach TOP!!

  2. Hallo,

    wäre es nicht möglich in deinen Beispiel auch statt der Zone frankysweb.org mit den beiden Host-A Einträgen 2 Zonen anzulegen, einmal autodiscover.frankysweb.org und einmal outlook.frankysweb.org mit einen * Host Eintrag?
    Sonst müssten ja alle externen Dienste, Webserver etc in der DNS Zone mitgeführt werden damit Sie weiterhin erreichbar sind, korrekt?

  3. Hallo!

    Ich arbeite mit Server 2008r2 und Exchange 2010 SP3.

    Ist das Anpassen/Ändern des CAS-Array unbedingt notwendig?

    Ich arbeite mit SplitDNS die URLs sind intern und extern gleich.

    Autodiscover funktioniert.

    Ich möchte vermeiden die ganzen Outlook Profile/Verbindungen anzupassen.

    Ansonsten mal wieder ein Top howto!!!

    Danke!

  4. Hallo Frank, ich hake nochmal nach.
    Ich habe bei einem Kunden ein käufliches Zertifikat im Einsatz und Split DNS. Da habe ich nichts an CAS Array geändert und es funktioniert anscheinend.
    Warum muß ich dann im Falle von Letsencrypt das CAS Array manipulieren?
    Oder übersehe ich etwas?
    Wie gesagt es sind viele Clients und ich möchte mir das handeln an den Outlookprofilen ersparen.
    Danke.

  5. Hallo,
    kann man diese Anleitung auch für Exchange Server 2016 verwenden?
    Ich habe hier auf einen Server Windows 2016 und Exchange 2016 installiert und die Domäne heißt: TestDomane.local.

    Danke schon für die Antwort

    1. Wenn Du eine neue Domäne aufsetzt, dann ist eine .local nicht ideal. Nutze lieber eine Subdomäne, die Du öffentlich erreichbar machen kannst.

  6. Ich möchte mich herzlichst bei Dir bedanken. Die Anleitung hilft auch wunderbar bei der sauberen Migration des Exchange zu Exchange Online, da hier ein valides SSL Zertifikat benötigt wird.
    Es gab jetzt beim SBS 2011 ein paar Probleme mit der Powershell und dem PackageManagement. Da gab es immer wieder Probleme, die aber mit der Hilfe aus den Kommentaren gelöst werden konnten. Auch die Kommentierenden hier ein Dank.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.