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.

19 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
  8. Hallo zusammen,

    ich hatte vor ein paar Monaten auch auf win-scme am Exchange 2019 CU5 umgestellt. Jetzt wollte ich mal wieder auf das aktuelle CU7 Upgraden und laufe in folgenden Fehler:
    Fehler:
    Der folgende Fehler wurde generiert, als „$error.Clear();
    Install-ExchangeCertificate -services „IIS, POP, IMAP“ -DomainController $RoleDomainController
    if ($RoleIsDatacenter -ne $true -And $RoleIsPartnerHosted -ne $true)
    {
    Install-AuthCertificate -DomainController $RoleDomainController
    }
    “ ausgeführt wurde: „Microsoft.Exchange.Management.SystemConfigurationTasks.AddAccessRuleUnauthorizedAccessException: Unzureichende Rechte zum Erteilen des Netzwerkdienstzugriffs auf das Zertifikat mit dem Fingerabdruck A3A9804DE68B129C811E4B7DC0149A989B4CC726. —> System.UnauthorizedAccessException: Certificate —> System.Security.Cryptography.CryptographicException: Der Schlüsselsatz ist nicht vorhanden.

    bei System.Security.Cryptography.Utils.CreateProvHandle(CspParameters parameters, Boolean randomKeyContainer)
    bei System.Security.Cryptography.Utils.GetKeyPairHelper(CspAlgorithmType keyType, CspParameters parameters, Boolean randomKeyContainer, Int32 dwKeySize, SafeProvHandle& safeProvHandle, SafeKeyHandle& safeKeyHandle)
    bei System.Security.Cryptography.RSACryptoServiceProvider.GetKeyPair()
    bei System.Security.Cryptography.RSACryptoServiceProvider..ctor(Int32 dwKeySize, CspParameters parameters, Boolean useDefaultKeySize)
    bei System.Security.Cryptography.X509Certificates.X509Certificate2.get_PrivateKey()
    bei Microsoft.Exchange.Security.Cryptography.X509Certificates.TlsCertificateInfo.CAPIAddAccessRule(X509Certificate2 certificate, AccessRule rule)
    — Ende der internen Ausnahmestapelüberwachung —
    bei Microsoft.Exchange.Security.Cryptography.X509Certificates.TlsCertificateInfo.CAPIAddAccessRule(X509Certificate2 certificate, AccessRule rule)
    bei Microsoft.Exchange.Security.Cryptography.X509Certificates.TlsCertificateInfo.AddAccessRule(X509Certificate2 certificate, AccessRule rule)
    bei Microsoft.Exchange.Management.SystemConfigurationTasks.ManageExchangeCertificate.EnableForServices(X509Certificate2 cert, AllowedServices services, String websiteName, Boolean requireSsl, ITopologyConfigurationSession dataSession, Server server, List`1 warningList, Boolean allowConfirmation, Boolean forceNetworkService)
    — Ende der internen Ausnahmestapelüberwachung —
    bei Microsoft.Exchange.Configuration.Tasks.Task.ThrowError(Exception exception, ErrorCategory errorCategory, Object target, String helpUrl)
    bei Microsoft.Exchange.Configuration.Tasks.Task.WriteError(Exception exception, ErrorCategory category, Object target)
    bei Microsoft.Exchange.Management.SystemConfigurationTasks.InstallExchangeCertificate.EnableForServices(X509Certificate2 cert, AllowedServices services)
    bei Microsoft.Exchange.Management.SystemConfigurationTasks.InstallExchangeCertificate.InternalProcessRecord()
    bei Microsoft.Exchange.Configuration.Tasks.Task.b__91_1()
    bei Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)“.

    Der Fingerprint passt zu dem von win-acme erstellten Zertifikat im Lokalen Zertifikatsspeicher. Wie kann ich das Problem beheben? Hat da evtl. wer einen Tip?

    Danke im Voraus.
    LG Olli

    Antworten
    • Ok, habe den Fehler selber schon gefunden als ich das aktuelle Zertfikat per –renew –force neu austellen wollte:
      Unable to set full control rights for network service: Some or all identity references could not be translated.
      Unable to set full control rights for administrators: Some or all identity references could not be translated.

      Also win-acme nochamsl mit –acl-fullcontrol „netzwerkdienst,administratoren“ gestartet und danach auch erfolgreich das CU7 Update durchgeführt.

      Antworten
  9. bekomme es einfach nicht hin. Kann mir jemand weiterhelfen?

    A simple Windows ACMEv2 client (WACS)
    Software version 2.1.14.996 (RELEASE, TRIMMED, 64-bit)
    Connecting to https://acme-v02.api.letsencrypt.org/
    IIS version 10.0
    Running with administrator credentials
    Scheduled task not configured yet
    Please report issues at https://github.com/win-acme/win-acme
    Running in mode: Unattended
    Target generated using plugin Manual: mail.xxxx and 1 alternatives

    [mail.xxxx] Cached authorization result: valid
    [autodiscover.xxx] Authorizing…
    [autodiscover.xxx] Authorizing using http-01 validation (SelfHosting)
    [autodiscover.xxx] Authorization result: invalid
    [autodiscover.xxx] {
    „type“: „urn:ietf:params:acme:error:unauthorized“,
    „detail“: „Invalid response from http://autodiscover.xxxx/.well-known/acme-challenge/UBjaAZVN0cFR-h73KUlEYV0GWSrSaG9ERod9y60OfXk [2a01:238:20a:202:1082::]: \“\\n\\n404 Not Found\\n\\nNot Found\\n“Netzwerkdienst,Administratoren“
    Der Befehl „“Netzwerkdienst,Administratoren““ ist entweder falsch geschrieben oder
    konnte nicht gefunden werden.

    C:\Users\Administrator\Downloads\win-acme.v2.1.14.996.x64.trimmed>–installation iis,script –installationsiteid 1 –script
    Der Befehl „–installation“ ist entweder falsch geschrieben oder
    konnte nicht gefunden werden.

    C:\Users\Administrator\Downloads\win-acme.v2.1.14.996.x64.trimmed>“./Scripts/ImportExchange.ps1″

    Antworten
  10. Hallo, ich habe alles wie in der Anleitung befolgt und Zertifikate für zwei DNS-Einträge erstellt.
    Im Exchange werden anders als hier gezeigt aber beide angezeigt: outlook.domäne.de und autodiscover.domäne.de, wobei beide 2 Monate gültig sind. Jedoch steht bei dem Autodiscover Zertifikat, dass dieser einen ungültigen Status hat.

    Habe ich da etwas falsch gemacht?

    Antworten
  11. Hi,

    danke für den Artikel. Wieder mal sehr aufschlussreich und einfach dargestellt.

    „–installation iis,script“ ist nicht notwendig. „–installation script“ ist ausreichend. Das Script weist aufgrund der Parameter „‚IIS,SMTP,IMAP,POP'“ ja eben auch den Webdiensten das Zertifikat zu.

    Sofern „–installation iis,script“ verwendet wird werden sogar zusätzliche Bindungen auf dem IIS für alle Hostnamen erstellt. Das ist meiner Ansicht nach nicht nur unschön sondern auch eine Änderung die zu sonderbaren Phänomenen führen kann.

    LG
    Timbo

    Antworten

Schreibe einen Kommentar