In Teil 1 wurden bereits die Vorbereitungen für Let’s Encrypt Zertifikate und Exchange 2010 durchgeführt. Dieser Artikel baut daher direkt auf Teil 1 auf.
In Teil 1 wurde die Exchange Organisation entsprechend angepasst, daher geht es in Teil 2 direkt weiter mit der Konfiguration den öffentlichen DNS.
Ich habe ich noch vergessen zu erwähnen, dass die komplette Umgebung auf Windows Server 2008 R2 installiert ist. Ich habe mich absichtlich für Server 2008 R2 entschieden, da es für Exchange 2010 eine weit verbreitete Plattform ist.
Öffentliches DNS
Damit Exchange über das Internet erreichbar ist, müssen am Öffentlichen DNS Server ebenfalls die entsprechenden DNS Einträge erstellt werden. In meinem Fall nutze ich Strato als Provider, daher werden dort auch die DNS Einträge erstellt. Damit Let’s Encrypt die DNS-Namen die später auf dem Zertifikat stehen sollen validieren kann, muss die Let’s Encrypt CA den Exchange Server mittels Port 80 (http) erreichen können. Daher werden die 3 DNS Namen auch am öffentlichen DNS Server bekannt gemacht:
- autodiscover.frankysweb.org
- outlook.frankysweb.org
- outlook.int.frankysweb.org
Die DNS Namen verweisen jeweils auf die öffentliche IP des Exchange Servers. In diesem Szenario ist es die WAN IP des Routers:
Der Router hat ein ein Portforward für Port 80 und 443 auf den Exchange Server konfiguriert:
Es muss also sichergestellt sein, dass die konfigurierten DNS Namen aus dem ersten Teil auch aus dem Internet erreichbar sind. Im Prinzip lässt sich dass ganz einfach prüfen, wenn unter jeder URL eine IIS Testseite aufgerufen werden kann, passt die Konfiguration.
An dieser Stelle dürfen die Browser übrigens noch eine Zertifikatswarnungen anzeigen, denn das gültige Zertifikat muss erst noch erstellt beantragt werden.
Let’s Encrypt
Meine Demoumgebung läuft auf Windows Server 2008 R2. Ich habe absichtlich den Exchange 2010 Server auf Server 2008 R2 installiert, denn diese Konstellation dürfte noch recht weit verbreitet sein.
Server 2008 R2 wird mit der PowerShell 2.0 ausgeliefert, diese ist nicht mehr zeitgemäß und muss daher aktualisiert werden, damit die nachfolgende Script funktioniert.
Für Server 2008 R2 und Exchange 2010 wird die PowerShell 4 unterstützt, daher kann das Windows Management Framework 4.0 installiert werden:
Windows Management Framework 4.0
das Windows Management Framework enthält unter anderem die PowerShell in der Version 4. Nach der Installation sollte der Befehl “get-host” die Version 4 der PowerShell anzeigen:
Hinweis: Die Exchange Management Shell wird weiterhin mit der PowerShell 2 gestartet, dies ist normal und verursacht keine Probleme für den weiteren Verlauf:
Nachdem die PowerShell Version aktualisiert wurde, muss PowerShellGet installiert werden, erst dann sind die nötigen CMDLets verfügbar um den LetsEncrypt Client zu installieren. Der entsprechende Download findet sich hier:
Nachdem PowerShellGet installiert wurde, stehen die CMDLets für die Installation bereit, jetzt kann der Let’s Encrypt Client “ACMESharp” installiert werden:
install-module -name ACMESharp
Jetzt ist es fast geschafft, denn die aktuelle Version des “Certtificate Assistant” unterstützt nun auch Exchange 2010.
Hinweis: Björn hat den ursprünglichen “Certificate Assistant” angepasst, damit er auch mit Exchange 2010 funktioniert. Seine Anpassungen haben in meiner Umgebung einwandfrei funktioniert. Ich habe dann noch einen Fehler beseitigt der auf meinem Mist gewachsen ist. Der Dank an dieser Stelle gehört also Björn!
Die aktuelle Version des “Certificate Assistant” gibt es hier:
Nach dem Download muss das Script nur noch mit der PowerShell 4 ausgeführt werden. Bitte nicht die Exchange Management Shell verwenden, sondern die zuvor aktualisierte Version der “normalen” Windows PwoerShell.
Ein Task zur Automatischen Erneuerung des Zertifikats kann ebenfalls direkt im Script angelegt werden:
Falls es bisher noch keine Registrierung bei Let’s Encrypt gegeben hat, wird der folgende Fehler angezeigt:
Das Script führt dann die Registrierung durch, beantragt das Zertifikat und weißt es dem Exchange Server zu:
