Exchange Certificate Assistant: Keine neue Version, aber eine (bessere) Alternative (WIN-ACME)

Vor längerer Zeit habe ich den Exchange Certificate Assistant zum letzten Mal aktualisiert. Das Script verwendet POSH-ACME als Client um Let’s Encrypt Zertifikate automatisch anzufordern, jedoch kommt es mit dem Script immer mal wieder zu Problemen. Da es mittlerweile aber eine deutliche bessere Variante, welche ebenfalls Unterstützung für Exchange Server (und weitere Services) gibt, werde ich den Exchange Certificate Assistant nicht mehr weiter entwickeln.

An dieser Stelle folgt daher ein kleiner Artikel um mittels WIN-ACME Client ein Zertifikat für Exchange Server via Let’s Encrypt anzufordern.

Der WIN-ACME bietet direkt eine Integration für Exchange Server an. Voraussetzung ist die PowerShell in Version 5. Der WIN-ACME Client kann hier runtergeladen werden:

Das ZIP-Archiv kann dann in einen beliebigen Ordner entpackt werden:

Exchange Certificate Assistant: Keine neue Version, aber eine (bessere) Alternative (WIN-ACME)

Alles was nun noch benötigt wird, sind die Namen, welche auf dem Zertifikat eingetragen werden sollen. Um die DNS-Namen für das Zertifikat zu ermitteln, kann das Script aus einem meiner vorigen Beiträge verwendet werden:

Danach kann der WIN-ACME Client mit entsprechenden Parametern gestartet werden. Um das Zertifikat für Exchange Server zu konfigurieren, kann der folgende Befehl mit den entsprechenden DNS-Namen angepasst werden:

1
wacs.exe --target manual --host outlook.frankysweb-lab.de,autodiscover.frankysweb-lab.de --certificatestore My --acl-fullcontrol "network service,administrators" --installation iis,script --installationsiteid 1 --script "./Scripts/ImportExchange.ps1" --scriptparameters "'{CertThumbprint}' 'IIS,SMTP,IMAP,POP' 1 '{CacheFile}' '{CachePassword}' '{CertFriendlyName}'"

Am einfachsten ist es, wenn der Befehl in eine CMD-Datei kopiert wird und dann dort angepasst wird:

Exchange Certificate Assistant: Keine neue Version, aber eine (bessere) Alternative (WIN-ACME)

Das waren schon alle nötigen Anpassungen, die CMD-Datei kann nun direkt ausgeführt werden. Alternativ lässt sich natürlich auch der Befehl aus der CMD Datei direkt in der Kommandozeile ausführen. Beim ersten Ausführen des WIN-ACME Clients müssen zwei Fragen bestätigt und eine E-Mail-Adresse angegeben werden:

Exchange Certificate Assistant: Keine neue Version, aber eine (bessere) Alternative (WIN-ACME)

Nachdem die Ausführung von WIN-ACME abgeschlossen ist, wurde das neue Zertifikat den Exchange Diensten zugewiesen:

Exchange Certificate Assistant: Keine neue Version, aber eine (bessere) Alternative (WIN-ACME)

Ebenfalls gibt es einen Task, welcher das Zertifikat automatisch erneuert.

Exchange Certificate Assistant: Keine neue Version, aber eine (bessere) Alternative (WIN-ACME)

Es ist also Zeit den Exchange Certificate Assistant in Rente zu schicken und auf den WIN-ACME Client umzustellen. Vielen Dank an das Team hinter dem WIN-ACME Client für die hervorragende Arbeit.

Der Exchange Certificate Assistant war zumindest eines der ersten Scripte, welche Zertifikate für Exchange Server anfordern und automatisch zuweisen konnten. :-)

Vor kurzen habe ich außerdem ein ausführliches Whitepaper zum Thema “Exchange Server und Zertifikate” veröffentlicht, wer sich bei dem Thema Zertifikate noch unsicher fühlt, findet in dem Whitepaper einen ganz guten Einstieg.

13 Gedanken zu „Exchange Certificate Assistant: Keine neue Version, aber eine (bessere) Alternative (WIN-ACME)“

  1. Danke für den Artikel!

    Vor dem Umstieg interessiert mich natürlich die Fragen, wie das mit einem bereits bestehenden Konto bei LE ist, wenn man bisher deinen Assistenten verwendet hat. Beim ersten Ausführen muss ja eine Email Adresse angegeben werden. Läuft das problemlos durch, wenn man die selbe Email Adresse eingibt, wie beim Certificate Assistant? Hast du das mal getestet?

    Vielen Dank!

    Antworten
    • Hab mir die Frage schon selber beantwortet. Zum Glück hat das Tool einen Test Modus :D

      Lief zumindest im Test Problemlos durch. Auch über TLS. Dann muss ich nicht immer Port 80 jedes mal öffnen :)

      Antworten
  2. Danke für den Artikel!

    Nachdem ich nun seit fast einem Jahr auf eine überarbeitete, etwas robustere Version vom ECA warte freue ich mich, dass du dies mit uns teilst. Besonders interessant finde ich an win acme, dass man damit (scheinbar) auch die Möglichkeit hat ein Zertifikat für Exchange ohne Port 80 ausstellen zu lassen (tls-alpn-01), was mir im Jahr doch einiges an Arbeit ersparen würde, wenn es so funktioniert wie ich das verstanden habe.

    Ich würde hier noch einmal einen Kommentar verfassen sobald ich dies erfolgreich zum laufen gebracht habe.

    Antworten
  3. Hi, in Verbindung mit der Sophos UTM benutze ich derzeit noch dein Script „Sophos UTM: Zertifikat der WAF mittels PowerShell exportieren“, welches bisher zuverlässig funktioniert :-)

    Nachdem ich plane, die Sophos UTM ggf. durch die Sophos XG Firewall zu ersetzen (die unterstützt ja bis heute kein Let’s Encrypt – anderes Thema…), habe ich mit der WIN-ACME zumindest für Exchange eine Alternative.
    Ich weiß nur noch nicht, ob Port 80 während der Zertifikatsanfrage/-Erneuerung Richtung Exchange-Server offen sein muss oder ob dies mit WIN-ACME hinfällig ist!?

    Antworten
    • Leider musste ich gestern feststellen, dass zwar meine ersten Test mit TLS liefen, aber im Zusammenhang mit dem Exchange Script immer wieder http vorgezogen wird. Auch nach Anpassung der settings Datei und zusätzlichem einfügen der unattended switches um den validatimode vorzugeben. Irgendwie scheint das Script da seinen eigenen Kopf zu haben. Leider bin ich dann gestern an die rate-limits gestoßen und muss heute noch drauf schauen. Im Moment ist win-acme für Exchange nur wie der alte Assistent über Port 80 lauffähig. Zumindest im unattended mode. Wenn man win-acme im voll manuellen Modus durchläuft geht es aber, da man hier den tls switch manuell setzen kann. Aber das Script jedesmal manuell neu zu konfigurieren ist auch nicht das Wahre.

      Antworten
  4. Danke für den Artikel,
    bei meinen ersten Tests lief die Zertifikat-Anforderung und Einbindung in einen Exchange 2016 im Staging und Live ohne grössere Probleme.
    Allerdings habe ich noch Warnungen im Log, auf die ich mir noch keinen Reim machen kann ( Ausführung lief mit Admin-Rechten)

    [INF] Adding certificate [Manual] autodiscover.danckelmann-kerst.de @ 2020.9.30 15:48:48 to store My
    [WRN] Unable to set full control rights for network service
    [WRN] Unable to set full control rights for administrators

    Anscheinend werden dem Zertifikat nicht alle vorgesehenen Rechte zugeordnet, hat schon jemand ne Idee woran das liegen mag?

    Antworten
    • Hab das gleiche Problem. Das Win-Acme-Team baut diesbezüglich in das nächste Build eine Logging-Funktion ein, um dem auf den Grund zu gehen.

      Antworten
      • Liegt sicherlich am deutschen Windows Server. Statt –acl-fullcontrol „network service,administrators“ solltet ihr –acl-fullcontrol „Netzwerkdienst,Administratoren“ verwenden

        Antworten
  5. Hab das mit einem frischen Exchange 2019 auf Server 2019 ausprobiert. Mit dem alten Script lief das. Mit Win-Acme fehlt die Bindung für SMTP und der Server macht beim Test kein TLS mehr. Alte Script wieder ausgeführt, alles geht. Warum wurde SMTP nicht gebunden und wo kann ich die Kommunikation über TLS einstellen und ausprobieren, damit ich Port 80 wieder dicht machen kann?

    Antworten
    • Hab noch ein bisschen probiert: 1. Win-ACME kann das Zertifikat nicht an den Sendeconnector binden. Auch manuell über Frankys Anleitung (https://www.frankysweb.de/exchange-2016-smtp-connector-und-wildcard-san-zertifikate/) scheitert es, da das Zertifikat nicht für SMTP enabled ist. Manuelles enablen geht auch nicht.
      2. Alle Zertifikate gelöscht und Win-ACME nochmals laufen lassen. Gleiches Ergebnis: SMTP kann dem Zertifikat nicht zugewiesen werden.
      3. „Add full control for networkservice and administrators“ scheitert bei meinem Server 2019. Egal ob cmd als Admin oder normal. Vlt. kann mit den Angaben jemand etwas mehr anfangen.
      4. Der Testmode (–testmode –verbose) bringt mich leider auch nicht weiter.

      Antworten
  6. eine kurze Frage: Der alte Zertifiakte Assistent hatte das Zertifiakt nicht mit IIS verbunden. Dieses neue Script tut das. Ist das notwendig? Ich stehe momentan auf dem schlauch?

    Antworten
  7. Moin,
    wenn ich ein Zertifikat mit dem Tool erfolgreich erstellt habe, was super funktioniert hat, ich aber doch eine Adresse im Zertifikat vergessen habe, kann ich das Zertifikat einfach im EX2019 löschen und dann neu erstellen? Muss etwas beachtet werden?

    Antworten

Schreibe einen Kommentar