Es ist schon wieder etwas länger her, dass ich hier einen Artikel bezüglich Exchange Server und Let’s Encrypt Zertifikat veröffentlicht habe. In der Zwischenzeit hat sich auch ein bisschen was geändert und ich erhalte recht viele Anfragen zu dem Thema, daher schreibe ich einen neuen Artikel.
Wie ihr wisst ist Let’s Encrypt eine öffentliche Zertifizierungsstelle, welche SSL Zertifikate mit einer Laufzeit von 90 Tagen kostenlos ausstellt. Let’s Encrypt wird von allen Browsern akzeptiert und ist dank der Automatisierung sehr einfach zu nutzen. Es sind allerdings ein paar Dinge zu beachten.
Exchange Server vorbereiten
Bevor Exchange Server aus dem Internet erreichbar gemacht werden, sollte man sich über die Konsequenzen bewusst sein. Exchange Server welche direkt aus dem Internet erreichbar sind, also ohne vorgeschaltete Web Application Firewall (WAF), sind ein lohnendes Angriffsziel. Es ist also zwingend notwendig, dass Exchange Server und auch das Betriebssystem immer auf dem aktuellen Stand gehalten werden. Das CERT-Bund hat erst kürzlich vor tausenden veralteten Exchange Servern gewarnt. Auch die Konfiguration muss permanent im Auge behalten werden, hier nimmt einem der Exchange Health Checker die meiste Arbeit ab. Am besten generiert man sich zyklisch einen Health Checker Bericht und prüft, ob die Konfiguration noch den Best Practises entspricht und keine Schwachstellen gefunden worden sind:
DNS Einstellungen kontrollieren
Wenn alle Updates installiert sind und Exchange Health Checker keine Probleme mehr findet, können die Hostnamen ermittelt werden, welche für das Zertifikat benötigt werden. Zum Ermitteln der Hostnamen kann das kleine Script aus dem folgenden Artikel verwendet werden, auch wenn es schon alt ist, es funktioniert problemlos mit Exchange Server 2019:
In den meisten Umgebungen sollten hier dann genau zwei Namen angezeigt werden: autodiscover.domain.de für Autodiscover und einen Zugriffspunkt für die restlichen Protokolle, beispielsweise outlook.domain.de. Sollte das Script noch weitere Namen anzeigen, beispielsweise exsrv.firma.local, dann habt ihr noch einen Konfigurationsfehler. Damit es später nicht zu Zertifikatswarnungen kommt, sollten hier also zunächst die Hostnamen entsprechend konfiguriert werden, auch dies lässt sich einfach per PowerShell erledigen:
Auch das Script ist schon alt, funktioniert aber ebenfalls problemlos mit Exchange 2019 (da hat sich nichts geändert). Falls Änderungen an den Hostnamen vorgenommen werden: DNS Einträge nicht vergessen! Es kann natürlich sein, dass es jetzt zu Zertifikatswarnungen in Outlook kommt, solange kein passendes Zertifikat für die konfigurierten DNS Namen konfiguriert ist.
Prüft am besten einmal die konfigurierten DNS Namen von intern und von extern. Die Prüfung kann auch via PowerShell erfolgen:
#Internal
Resolve-DnsName outlook.domain.de
Resolve-DnsName autodiscover.domain.de
#External
Resolve-DnsName autodiscover.domain.de -Server 8.8.8.8
Resolve-DnsName outlook.domain.de -Server 8.8.8.8
Gegen den internen DNS (üblicherweise die Domain Controller) sollte die interne IP des Exchange Servers aufgelöst werden, gegen einen externen DNS Server (im Beispiel Google) die öffentliche IP. Hier ein Beispiel:
Es ist wichtig, dass die Namensauflösung sauber funktioniert. Lets‘ Encrypt wird sonst kein Zertifikat ausstellen.
Firewall Freigaben kontrollieren
Der nächste wichtige Punkt sind Freigaben in der Firewall. Damit Let’s Encrypt ein Zertifikat ausstellt, muss der Exchange Server mindestens via Port 80 (http) und Port 443 (https) aus dem Internet erreichbar sein. Port 25 (smtp) lasse ich für diesen Artikel mal außer Betracht.
Bei kleinen Firmen wird dazu meistens eine Portweiterleitung im Router konfiguriert, da die Konfiguration je nach Router / Firewall unterschiedlich ist, kann ich das hier nicht ausführlich beschreiben, daher hier nur ein kleines Beispiel aus einem UniFi Cloud Gateway:
Bei manchen Routern / Firewalls ist neben der Portweiterleitung auch noch das Öffnen des Ports in der Firewall erforderlich.
Ob der Zugriff von extern funktioniert, lässt sich ja recht einfach mit einem Smartphone via LTE testen. Dazu kann einfach die OWA Webseite aufgerufen werden. Wenn diese von extern aufgerufen werden kann, könnt ihr davon ausgehen, dass es funktioniert.
Zertifikat automatisieren
Um ein Zertifikat von Let’s Encrypt anzufordern, bei Bedarf zu erneuern und automatisch für Exchange Server zu konfigurieren, kann der WIN-ACME Client verwendet werden. WIN-ACME unterstützt neben Exchange Servern auch eine ganze Reihe weiterer Software wie RD Gateway und SQL Server.
Damit ein Zertifikat für den Exchange Server ausgestellt und konfiguriert werden kann, muss zunächst der WIN-ACME Client auf dem Exchange Server entpackt werden, in diesem Beispiel nach D:\win-acme:
In dem Verzeichnis befindet sich die Datei settings_default.json, diese Datei kann nun mit dem Editor geöffnet werden. In der Datei findet sich unter dem Oberpunkt „Store“ die Einstellung „PrivateKeyExportable“. Diese Einstellung steht in der Standardeinstellung auf „false“. Damit ihr später das Zertifikat exportieren könnt, wird diese Einstellung auf „true“ gesetzt und die Datei gespeichert:
Um ein Zertifikat anzufordern und automatisch für Exchange zu konfigurieren, müsst ihr euch einen Befehl etwas anpassen. Achtung: Sprache des Betriebssystems beachten.
Wenn Exchange auf einem Betriebssystem in deutscher Sprache installiert ist, könnt ihr den folgenden Befehl verwenden und die Hostnamen outlook.domian.de undautodiscover.domain.de entsprechend austauschen (hier werden die Berechtigungen für Administratoren und den Netzwerkdienst konfiguriert):
wacs.exe --source manual --host outlook.domian.de,autodiscover.domain.de --certificatestore My --acl-fullcontrol "Netzwerkdienst,Administratoren" --installation iis,script --installationsiteid 1 --script "./Scripts/ImportExchange.v2.ps1" --scriptparameters "'{CertThumbprint}' 'IIS,SMTP,IMAP' 1 '{CacheFile}' '{CachePassword}' '{CertFriendlyName}'"
Wenn Exchange auf einem Betriebssystem in englischer Sprache installiert ist, könnt ihr den folgenden Befehl verwenden und die Hostnamen outlook.domian.de undautodiscover.domain.de entsprechend austauschen (hier werden die Berechtigungen für Administrators und den Networkservice konfiguriert):
wacs.exe --source manual --host outlook.domian.de,autodiscover.domain.de --certificatestore My --acl-fullcontrol "network service,administrators" --installation iis,script --installationsiteid 1 --script "./Scripts/ImportExchange.v2.ps1" --scriptparameters "'{CertThumbprint}' 'IIS,SMTP,IMAP' 1 '{CacheFile}' '{CachePassword}' '{CertFriendlyName}'"
Wenn der Befehl ausgeführt wird, muss beim ersten Start den Nutzungsbedingungen zugestimmt werden und eine E-Mail Adresse für Benachrichtigungen angegeben werden:
Der Rest passiert jetzt automatisch. Für die Erneuerung des Zertifikats wird automatisch eine geplante Aufgabe erstellt, welche sich um das Update kümmert:
Das Zertifikat wurde auch bereits an die Exchange Services gebunden und aktiviert, hier muss also nichts mehr manuell gemacht werden.
Zertifikat prüfen
Zum Schluss sollte noch geprüft werden, ob das Zertifikat richtig konfiguriert ist. Outlook darf keine Zertifikatsfehlermeldung liefern, auch interne und externe Zugriffe via Browser (natürlich auch Outlook), müssen ebenfalls ohne Zertifikatsfehlermeldungen funktionieren. Kommt es trotzdem noch zu Fehlermeldungen, liegt das Problem zu 99% als falsch konfigurierten Hostnamen in der Exchange konfiguration oder auf dem Zertifikat.
Let’s Encrypt Zertifikat sind wie erwähnt 90 Tage gültig, es macht also Sinn sich einen Eintrag im Kalender in 80 Tagen zu machen und zu schauen, ob das Zertifikat getauscht wurde und alles problemlos funktioniert hat.