Tags: Zertifikate, Exchange, Web-Server
Für öffentlich zugängliche Websites sind SSL-Verbindungen mittlerweile Standard, und Ähnliches sollte auch für Exchange gelten. Let's Encrypt betreibt eine freie CA, die Zertifikate nicht nur kostenlos, sondern auch weitgehend automatisiert ausstellt. Diese Anleitung zeigt das Vorgehen für IIS und Exchange.
Die CA von Let's Encrypt stellt Zertifikate für einzelne Hosts oder SAN-Zertifikate aus, Wildcard-Zertifikate werden seit Anfang 2018 unterstützt. Dabei sollte man wissen, dass die Zertifikate nur 90 Tage gültig sind. Daher empfiehlt sich für die regelmäßige Verlängerung das Einrichten eines Automatismus.
Zahlreiche ACME-Clients
Um zu verifizieren, dass der Antragsteller die Domäne kontrolliert, für die er ein Zertifikat ausstellen möchte, nutzt Let's Encrypt das ACME-Protokoll (steht für Automatic Certificate Management Environment).
Let's Encrypt selbst bietet keine eigenen ACME-Clients an, aber es gibt eine ganze Reihe davon für alle möglichen Plattformen. Wir verwenden hier win-acme, ein freies Konsolenprogramm für Windows von Tinus Wouter.
Die Version 2.0 liegt aktuell als Beta vor und erfordert das .NET-Framework 4.7.2. In meinem Test stürzte das Tool aber gleich beim Start ab, so dass hier die stabile v1.9.12.2 zum Einsatz kommt. Wenn man Wildcard-Zertifikate anfordern möchte, dann ist dafür das ACME2-Protokoll notwendig, welches von diesem Tool erst ab der Version 2.0 unterstützt wird.
Verifizierung erfordert Erreichbarkeit über das Internet
Egal welche Methode zur Verifizierung der Domäne man wählt, allen ist gemeinsam, dass der FQDN über einen öffentlichen DNS-Server auflösbar und der Host auf Port 80 über das Internet erreichbar ist.
Das gilt auch, wenn man sich für die Verifizierung mittels Datei entscheidet, die der Client auf den lokalen Rechner herunterlädt. Diese muss dann auf den Host kopiert werden und dort für Let's Encrypt zugänglich sein.
In unserem Beispiel entscheiden wir uns dafür, win-acme die Bindungen einer IIS-Site auslesen zu lassen, So dass der ACME-Client die Namen der Hosts aus der IIS-Konfiguration ermittelt. Daher müssen wir im IIS-Manager sicherstellen, dass HTTP bei den gewünschten Sites an die jeweiligen FQDN gebunden ist.
Interaktive Anforderung des Zertifikats
Ist diese Voraussetzung gegeben, dann starten wir den ACME-Client namens letsencrypt.exe. Dieser präsentiert nach der Bestätigung der Nutzungsbedingungen ein textorientiertes Menü, aus dem wir "N" für ein neues Zertifikat auswählen.
Im Anschluss daran entscheiden wir uns wie für 3, also für "SAN Certificate for all bindings of multiple IIS sites”. Exchange hat nämlich seit der Version 2013 zwei IIS-Sites, die ein Zertifikat benötigen. Danach wählen wir als Methode die Option 3 "[http-01] Create temporary application in IIS".
Nach erfolgreicher Ausstellung des Zertifikats legt es letsencrypt.exe unter C:\ProgramData\win-acme\httpsacme-v01.api.letsencrypt.org ab.
Der ACME-Client bietet dann noch an, eine geplante Aufgabe für die automatische Erneuerung des Zertifikats anzulegen. Für eine reine IIS-Umgebung wird man davon Gebrauch machen, so dass der Vorgang dort nun beendet ist.
Wenn alles gut gegangen ist, dann sollte das Zertifikat im IIS installiert sein. Wenn nicht, dann lässt es sich im IIS Manager aber schnell per Hand zuweisen.
Zertifikat an POP, IMAP, SMTP zuweisen
Benötigt man das Zertifikat für Exchange, dann haben an dieser Stelle noch nicht alle Dienste ein Zertifikat. Das könnte man nun manuell in der Web-Konsole nachholen, stattdessen nutzen wir dafür das Script ExchangeLetsEncrypt.ps1 von Anthony Eden.
Es verlangt zwei Parameter, nämlich CertificateImport (für den Pfad zur PFX-Datei, die Let’s Encrypt generiert hat, normalerweise unter C:\ProgramData\letsencrypt-win-simple\httpsacme-v01.api.letsencrypt.org) sowie RDCB (der FQDN des Servers).
Zertifikat verlängern
Aufgrund der auf 90 Tage begrenzten Gültigkeit des Zertifikats muss man aufpassen, dass man dessen Erneuerung nicht versäumt. Am besten richtet man dafür eine geplante Task ein. Diese sollte nicht nur den ACME-Client mit dem renew-Parameter enthalten, sondern nach Möglichkeit auch das eben erwähnte PowerShell-Script:
Der Autor des Scripts liefert eine Batch-Datei (ExchangeInstallLE.bat) mit, die diese beiden Befehle enthält und die man nur mehr auf die eigene Umgebung anpassen muss.
Damit ist sichergestellt, dass das erneuerte Zertifikat gleich wieder an alle Exchange-Services zugewiesen wird.
Täglich Know-how für IT-Pros mit unserem Newsletter
Roland Eich ist gelernter Fachinformatiker für Systemintegration und in der IT seit über 14 Jahren zu Hause. Roland deckt aufgrund seiner Erfahrungen ein breites Spektrum der Microsoft-Produktpalette ab.Zudem besitzt er verschiedene Zertifizierungen (MCITP, MCSA und MCSE, ITIL, PRINCE2).
// Kontakt: E-Mail //
Verwandte Beiträge
- Exchange 2019 CU14 aktiviert Extended Protection, HSTS-Support für 2016 und 2019 ab sofort
- Outlook-Kontakte verschwinden nach Import vom globalen Adressbuch
- SSL-Zertifikat für IIS und WSUS installieren auf Server Core
- Zertifikat für Windows Root CA erneuern
- Exchange 2019 CU14 verschiebt sich auf 2024, danach nur mehr ein CU
Weitere Links
4 Kommentare
Hallo, habe die Schritte bis zum Punkt:"Interaktive Anforderung des Zertifikats" ausgeführt, mit dem Ergebnis, dass nun mein Exchange nicht mehr aufrufbar ist und es sofort viele Fehlermeldungen erscheine, sobald man die Exchange-Konsole öffnet. Hängt das mit der IIS-Bindung zusammen? Rückgängig kann man den Prozess nun auch nicht machen?
Muss Port 80 offen bleiben für die automatische Verlängerung des Certs?
Gute Anleitung! Leider im Detail nicht mehr aktualisiert worden.
In der aktuellen Version haben sich die Schritte etwas geändert.
@Fabi: Kannst du sagen, welche Schritte sich wie geändert haben?