Eigentlich wollte ich an einem Sonntagvormittag nur kurz etwas ausprobieren: ein Let’s-Encrypt-Zertifikat für meine neue Testdomain squeakylobster.dev ausstellen, per DNS-Validierung über Cloudflare, und das Ganze anschließend als Transport-Zertifikat auf einem Exchange Server einbinden. Klingt nach einer halben Stunde Arbeit. Am Ende standen ein Toolwechsel, ein fehlerhaftes Referenzskript, eine RBAC-Frage und eine ziemlich grundsätzliche Erkenntnis zum Thema Let’s Encrypt und SMTP.
Weil viele von euch Let’s Encrypt in Labs, in kleineren Umgebungen oder für einzelne Namespaces einsetzen, lohnt sich ein genauerer Blick. Gerade 2026 hat sich rund um ACME-Clients und Let’s-Encrypt-Zertifikate einiges getan, was direkte Auswirkungen auf Exchange hat.
Hintergrund: Warum win-acme nicht mehr die erste Wahl ist
Wer in den letzten Jahren auf einem Windows Server Let’s-Encrypt-Zertifikate automatisiert hat, kam an win-acme kaum vorbei. Das Tool ist schlank, kommandozeilenorientiert und bringt seit Langem Beispielskripte für Exchange mit. Genau dort beginnt aber schon die erste Überraschung: Im Scripts-Ordner liegen mit ImportExchange.ps1 und ImportExchange.v2.ps1 zwei Varianten. Die Dokumentation verweist ausschließlich auf die v2, viele Anleitungen im Netz nutzen aber noch die alte Version, meist im interaktiven Modus.
Die wichtigere Entwicklung ist allerdings eine andere. win-acme ist faktisch am Ende seiner Entwicklung. Nachdem ZeroSSL das Projekt übernommen hatte, hat der ursprüngliche Hauptentwickler Wouter Tinus seinen eigenen Code geforkt und führt ihn als simple-acme weiter. simple-acme setzt auf win-acme 2.2.9.1, ist vollständig abwärtskompatibel und wird aktiv weiterentwickelt. Die Hintergründe beschreibt er selbst auf der Seite zur Projekthistorie. Weitere Releases von win-acme erwartet er nicht.
Für uns Admins ist der Umstieg denkbar unspektakulär. Das Executable heißt weiterhin wacs.exe, die Parameter sind identisch, bestehende Befehlszeilen funktionieren weiter. Eine Änderung solltet ihr aber kennen: Die Beispielskripte liegen nicht mehr im Download, sondern in einem eigenen Repository, den simple-acme reference-scripts. Das Exchange-Skript findet ihr dort unter Installation/ImportExchange.v2.ps1.
Der Weg zum Zertifikat
DNS-Validierung über Cloudflare
Für Exchange bietet sich die DNS-01-Validierung an. Ihr müsst keinen Port 80 nach innen öffnen, und Namen wie AutoDiscover lassen sich problemlos validieren. simple-acme bringt dafür ein Cloudflare-Plugin mit, das als separater Download auf der Download-Seite bereitsteht. Voraussetzung ist der pluggable Build von simple-acme, die Plugins gehören nach %ProgramData%\simple-acme\plugins.
Ein Stolperstein, der gern übersehen wird: Das Plugin erwartet ein Cloudflare API Token, keinen Global API Key. Das Token benötigt die Berechtigungen Zone/DNS/Edit und Zone/Zone/Read und sollte idealerweise auf die eine Zone beschränkt sein.
Erst Staging, dann Produktion
Den ersten Lauf solltet ihr immer mit --test gegen die Staging-Umgebung von Let’s Encrypt durchführen. Das schont die Rate Limits und zeigt, ob Token, Plugin und Installationsskript zusammenarbeiten. Das Staging-Zertifikat erkennt ihr am Issuer mit dem Präfix “(STAGING)”. Nach dem erfolgreichen Test den Staging-Renewal über das Menü von wacs.exe abbrechen, sonst läuft er dauerhaft im Scheduled Task weiter.
Welche Rechte braucht das ausführende Konto?
Für das Binden des Zertifikats reicht die Managementrolle „Exchange Server Certificates“. Sie enthält alle Certificate-Cmdlets und ist standardmäßig den Rollenmitgliedern der Rollen Organization Management und Server Management zugewiesen. Meine Empfehlung ist eine dedizierte Rollengruppe mit genau dieser Rolle, eingeschränkt auf die betroffenen Server per Management Scope, und ein eigenes Dienstkonto. Wer das nicht pflegen möchte, nimmt Server Management. Organization Management ist für einen automatisierten Task schlicht zu breit gefasst.
Dazu kommen lokale Administratorrechte, weil simple-acme in den Maschinenstore schreibt und ACLs auf den Private Key setzt, sowie RemotePowerShellEnabled am Konto. Und ein Punkt, den man leicht übersieht: Euer manueller Testlauf läuft unter eurem Admin-Konto, der Scheduled Task von simple-acme aber standardmäßig als SYSTEM. Testet die Installationsphase also auch in diesem Kontext, oder hinterlegt das Dienstkonto direkt im Task.
Praxisbeispiel: Transport-Zertifikat auf SRV-VAR-EXCH-01
Das Zertifikat soll die Namen smtp.squeakylobster.dev, mail.squeakylobster.dev und autodiscover.squeakylobster.dev enthalten. Da es primär um den Transport geht, steht smtp an erster Stelle und wird damit zum Common Name. IIS lasse ich bewusst außen vor, um bei Problemen nicht zwei Baustellen gleichzeitig zu haben.
$sa = "$env:ProgramFiles\simple-acme"
& "$sa\wacs.exe" --source manual `
--host smtp.squeakylobster.dev,mail.squeakylobster.dev,autodiscover.squeakylobster.dev `
--validation cloudflare --cloudflareapitoken '<TOKEN>' `
--store certificatestore --certificatestore My `
--acl-fullcontrol "network service,administrators" `
--installation script `
--script "$sa\scripts\ImportExchange.v2.ps1" `
--scriptparameters "'{CertThumbprint}' 'SMTP' 1 '{CacheFile}' '{CachePassword}' '{CertFriendlyName}'" `
--accepttos --emailaddress certwatch@squeakylobster.dev `
--test
Nach dem erfolgreichen Staging-Lauf denselben Befehl ohne --test ausführen und das Ergebnis prüfen:
Get-ExchangeCertificate -Server SRV-VAR-EXCH-01 |
Where-Object { $_.Subject -like '*squeakylobster*' } |
Format-List Thumbprint, Issuer, CertificateDomains, Services, NotAfter
Damit ist der Job aber noch nicht erledigt. Hat ein weiteres Zertifikat ebenfalls SMTP gebunden, entscheidet Exchange pro Receive Connector anhand des Connector-FQDN oder eines explizit gesetzten TlsCertificateName, welches Zertifikat beim STARTTLS ausgeliefert wird. Ich empfehle bei Let’s Encrypt den Weg über den FQDN:
Set-ReceiveConnector "SRV-VAR-EXCH-01\Default Frontend SRV-VAR-EXCH-01" -Fqdn smtp.squeakylobster.dev
Das ist erneuerungsfest, denn TlsCertificateName enthält Issuer und Subject. Let’s Encrypt signiert aber mit wechselnden Intermediates, und spätestens bei der nächsten Erneuerung zeigt ein explizit gesetzter Name dann ins Leere. Zum Schluss von außen prüfen:
openssl s_client -starttls smtp -connect smtp.squeakylobster.dev:25 -servername smtp.squeakylobster.dev
Bevor das erste Zertifikat ausgestellt wird, lohnt ein Blick darauf, was bei der DNS-01-Validierung eigentlich zwischen den Beteiligten passiert. simple-acme bestellt das Zertifikat bei Let’s Encrypt und erhält für jeden Hostnamen eine eigene Challenge zurück. Für jede dieser Challenges ermittelt simple-acme über die Cloudflare API zunächst die passende Zone und legt dort einen TXT-Record unter _acme-challenge an. Bei drei Hostnamen läuft dieser Zyklus also dreimal.
Bevor simple-acme Let’s Encrypt grünes Licht gibt, prüft es selbst bei den autoritativen Nameservern, ob der Record bereits sichtbar ist. Diese Pre-Validation erspart euch fehlgeschlagene Autorisierungen, weil Let’s Encrypt erst dann prüft, wenn der Record tatsächlich publiziert ist. Ist die Autorisierung erfolgreich, räumt simple-acme den TXT-Record wieder ab. Erst wenn alle Hostnamen validiert sind, folgt der CSR, und Let’s Encrypt stellt das Zertifikat aus.
Das Diagramm zeigt außerdem, wofür die beiden Berechtigungen des API-Tokens verwendet werden. Zone/Zone/Read dient dazu, die Zone-ID zu ermitteln, Zone/DNS/Edit zum Anlegen und Löschen der Records. Fehlt eine der beiden, scheitert der Ablauf bereits im ersten Schritt der Schleife.
Der Elefant im Raum - Client Authentication EKU
Ein Thema, das 2026 für viel Unruhe gesorgt hat: Let’s Encrypt entfernt die TLS Client Authentication EKU aus seinen Zertifikaten. Auslöser sind die Vorgaben des Chrome Root Programs, die die Client- und Server-Authentifizierung in getrennte PKIs aufzuteilen. Andere öffentliche CAs gehen denselben Weg. Ein typisches Zertifikat enthält damit nur noch die Server-Authentication-EKU.
In der Exchange-Community lag die Sorge nahe, dass der Hybrid-Mailflow darunter leidet. Beim Versand an Exchange Online präsentiert der On-Premises-Server sein Zertifikat als TLS-Client, und der Inbound Connector in Exchange Online prüft dieses Zertifikat anhand der Eigenschaft TlsSenderCertificateName. Die gute Nachricht: Für Exchange Hybrid ist die Client Auth EKU nicht mehr notwendig. Exchange Online akzeptiert für den zertifikatbasierten Inbound Connector auch Zertifikate, die ausschließlich die EKU Server Authentication enthalten. Ihr könnt ein Let’s-Encrypt-Zertifikat auch für den Hybrid-Mailflow verwenden.
Ganz ohne Haken ist das trotzdem nicht. Der Send Connector Outbound to Office 365 referenziert das Zertifikat über den TlsCertificateName, und darin sind Issuer und Subject enthalten. Let’s Encrypt signiert mit wechselnden Intermediates, sodass sich der Issuer bei einer Erneuerung ändern kann. Dann findet Exchange das Zertifikat für den Connector nicht mehr, und der Mailflow in Richtung Exchange Online bricht zusammen. Wer Let’s Encrypt in einer Hybrid-Umgebung nutzt, sollte den TlsCertificateName daher im Installationsskript nach jeder Erneuerung mitpflegen oder zumindest per Monitoring prüfen.
Relevant bleibt die fehlende EKU außerdem bei Partnern, deren Mailserver für zertifikatbasierte Verbindungen strikt eine Client-Auth-EKU verlangen. Das ist selten, aber wenn ihr solche Konstellationen habt, lohnt ein Test vor der Umstellung.
Fazit
simple-acme ist für mich der klare Nachfolger von win-acme, und wer neu startet, sollte direkt dort einsteigen. Die Cloudflare-Validierung lässt sich schnell einrichten, sofern ihr einen API-Token statt des Global Keys verwendet. Dem Referenzskript für Exchange solltet ihr dagegen nicht blind vertrauen. Prüft nach jedem Lauf, ob das Zertifikat tatsächlich an die gewünschten Dienste gebunden ist, und setzt auf eine angepasste Version mit sauberer Fehlerbehandlung.
Eine ausführliche Schritt-für-Schritt-Anleitung folgt als KB-Artikel.
