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:
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:
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:
Nachdem die Ausführung von WIN-ACME abgeschlossen ist, wurde das neue Zertifikat den Exchange Diensten zugewiesen:
Ebenfalls gibt es einen Task, welcher das Zertifikat automatisch erneuert.
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.
Hallo,
wir hatten auch das Problem, dass das Zertifikat nicht mehr für den Dienst SMTP aktiviert wurde. Unter https://github.com/win-acme/win-acme/discussions/2657 habe ich unsere Version des Skripts beschrieben.
Hallo,
das Script funktioniert unter Beachtung der unten angegeben Themen ohne Probleme! SUPER (https://www.win-acme.com V 2.2.8)
Exchange 2019 CU14.2 V15.2.1544.11
Zu beachten ist:
– als Administrator starten in Powershell
– Port 80 muss zum Exchange Server freigegeben sein
– Eintrag der richtigen DNS-Namen im „Start Script“ (owa.Server.de,autodiscover.Server.de)
– deutsche Installation Rechte „–acl-fullcontrol „Netzwerkdienst,Administratoren“ im „Start Script“
– das gesamte Script in eine Zeile kopieren (sonst werden nicht alle Angaben verarbeitet) „Start Script, z.B. Start.cmd“
– in der settings.json die Einstellung “PrivateKeyExportable” auf “True” setzen
– ./Scripts/ImportExchange.ps1“ muss in „./Scripts/ImportExchange.v2.ps1“ geändert werden
@Franky nochmals vielen DANK! Vielleicht kann man die Anmerkungen ja direkt in die Vorlagen einfügen ;)
Gruß
Horst
Hallo,
kleines Update dazu:
Wenn man die Zeilen oben einfach kopiert und im Editor mit dem original von Franky ergänzt kann es zu einem „Schriftartenproblem“ kommen.
Konkret ist dann – nicht – und “ nicht “
falsch: –acl-fullcontrol „Netzwerkdienst,Administratoren“
richtig: –acl-fullcontrol „netzwerkdienst,administratoren“
Kann man lange nach suchen, habe ich auch :)
Das so alles in eine Zeile rein, die DNS-Namen anpassen und es funktioniert.
.\wacs.exe –target manual –host outlook.mydomain.de,autodiscover.mydomain.de –certificatestore My –acl-fullcontrol „netzwerkdienst,administratoren“ –installation iis,script –installationsiteid 1 –script „./Scripts/ImportExchange.v2.ps1“ –scriptparameters „‚{CertThumbprint}‘ ‚IIS,SMTP,IMAP,POP‘ 1 ‚{CacheFile}‘ ‚{CachePassword}‘ ‚{CertFriendlyName}'“
Hatte es mir fast gedacht, das liegt an der Forumssoftware (denke ich mal).
Mein Eintrag oben ist jetz also genau so falsch (- und „)
Das wird wohl umkonvertiert wenn man es hier postet.
@franky: kannst du ggf. den Eintrag bei Dir direkt bereinigen bzw. den Eintrag von mir und oder Horst bereinigen ?
Hallo zusammen,
man liest ja immer mehr das diese Anleitung wohl nicht mehr funktioniert.
Das Mapping ans SMTP-Protokoll funktioniert bei mir auch nicht, auch kommen viele Fehlermeldungen und die ImportExchange.ps1 Datei will er mir auch nur mit dem Notepad öffnen.
Vielleicht kann hier jemand unterstützen? Oder man aktualisiert mal diese Anleitung?
Ich hänge auch gerade an dem Thema Zertifikate und Exchange.
Ich habe deine Anleitung zum Aufbau einer kleinen Exchange 2016 Umgebung befolgt. Dort beschreibst du ja den Weg über Startcom. Diese bieten ja leider keine Zertifikate mehr an. Deshalb der Weg über Letsencrypt.
Bei mir funktioniert dies allerdings nicht so richtig, da ich Timeouts und DNS-Fehler bekomme.
Wenn ich das richtig verstanden habe, muss der Exchange von außen über das Internet erreichbar sein, damit WinACME die Zertifikate bei Letsencrypt anfordern kann, richtig?
Freue mich über Tipps.
Hallo, habe hier gestern schon einen Kommentar geschrieben – habe das gleiche Problem wie Ingo (das Mapping ans SMTP-Protokoll funktioniert nicht). Die Anpassungen von kirstein aus dem neuesten Kommentar habe ich auch schon ausgetestet.
Mein gestriger Kommentar ist allerdings im Spam gelandet, da ich ihn über eine IP versendet habe, die von Askimet wohl als Spam geblacklistet ist.
Bitte um Freigabe meines Kommentars, falls möglich. Bin so oder so für jeden Tipp in dieser Sache dankbar. Sofern ich was herausgefunden habe, gebe ich hier auch Bescheid.
Tatsächlich ging es mir gestern auch so.
Das Zertifikat wurde einfach nicht dem SMTP Dienst zugewiesen.
Zumindest wurde es nicht angezeigt. Fehlermeldungen gab es keine.
Geholfen hat bei mir die Kommentare und Tips auf dieser Seite zu lesen.
Zwei Hinweise
– deutsche Installation Rechte „–acl-fullcontrol „Netzwerkdienst,Administratoren“
– In der settings.json lässt sich dazu die Einstellung “PrivateKeyExportable” auf “True” setzen:
in Kombination mit
– Zertifikat mit den Änderungen neu Ausstellen
– Zertifikat in eine Datei exportieren
– Zertifikat in der ecp Konsole erst von Diensten befreien bzw. auf das selbsignierte Zertifikat legen, dann löschen.
– neu importieren mit Import-ExchangeCertificate
– mit Enable-ExchangeCertificate den Diensten zuweisen,
hat es zum Laufen gebracht.
Ich habe das Gefühl das es auch einfacher gehen würde aber so ließ sich die verknotete Situation wieder retten.
Danke für diese Webseite
Jochen
Vielen lieben Dank fürs teilen! Hat tatsächlich so auch bei mir funktioniert.
Hallo allerseits,
bei dem oben aufgeführten Befehl für die Installation des Zertifikates ist mit aktuellen Version (v2.2.4.1500) von win-acme eine Anpassungen erforderlich:
„./Scripts/ImportExchange.ps1“ muss in „./Scripts/ImportExchange.v2.ps1“ geändert werden.
Außerdem sei noch darauf hingewiesen, dass bei einer deutschen Installation die Rechte nur mit ‚–acl-fullcontrol „Netzwerkdienst,Administratoren“‚ richtig gesetzt werden.
Hallo,
hat schon jemand eine Lösung für das Problem gefunden? Bei mir ist es genau das gleiche.
Oh hier ging was schief. Die Frage bezieht sich auf das Problem mit der fehlenden Bindung an den SMTP Dienst.
D:\Zertifikate\win-acme>“network service,administrators“
Der Befehl „“network service,administrators““ ist entweder falsch geschrieben oder
konnte nicht gefunden werden.
D:\Zertifikate\win-acme>–installation iis,script –installationsiteid 1 –script
Der Befehl „–installation“ ist entweder falsch geschrieben oder
konnte nicht gefunden werden.
D:\Zertifikate\win-acme>“./Scripts/ImportExchange.ps1″
Tut mir leid, aber ich benutze weiterhin die bisherigen Skripte dafür, aber danke.
Hallo,
ich habe einen Exchange 2019 mit aktuellsten Patch. Wenn ich das noch aktuelle Zertifikat mit WinACME ersteze, dann ist der OWA und der ECP nicht mehr erreichbar.
hat jemand eine Idee?
Grüße Rainer Schenkel
Beim EPC bekomme ich folgendes:
Serverfehler in der Anwendung /ecp.
https://localhost/owa/auth/errorFE.aspx?CafeError=SSLCertificateProblem
Beschreibung: Unbehandelte Ausnahme beim Ausführen der aktuellen Webanforderung. Überprüfen Sie die Stapelüberwachung, um weitere Informationen über diesen Fehler anzuzeigen und festzustellen, wo der Fehler im Code verursacht wurde.
Ausnahmedetails: System.Web.HttpException: https://localhost/owa/auth/errorFE.aspx?CafeError=SSLCertificateProblem
Quellfehler:
Beim Ausführen der aktuellen Webanforderung wurde einen unbehandelte Ausnahme generiert. Informationen über den Ursprung und die Position der Ausnahme können mit der Ausnahmestapelüberwachung angezeigt werden.
Stapelüberwachung:
[HttpException (0x80004005): https://localhost/owa/auth/errorFE.aspx?CafeError=SSLCertificateProblem%5D
Microsoft.Exchange.HttpProxy.FbaModule.OnBeginRequestInternal(HttpApplication httpApplication) +441
Microsoft.Exchange.HttpProxy.c__DisplayClass20_0.b__0() +1679
Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(Action tryDelegate, Func`2 filterDelegate, Action`1 catchDelegate) +35
System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +142
System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step) +75
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +93
Versionsinformationen: Microsoft .NET Framework-Version:4.0.30319; ASP.NET-Version:4.8.4494.0
Kurze Info, scheinbar hat sich mit einem der letzten Exchange 2016/2019 CUs etwas an dem Powershell Script geändert. Das Cmdlet Import-ExchangeCertificate akzeptiert kein File mehr. Dafür muss „-FileData“ mitgeliefert werden. Siehe Text zum Example2 unter https://docs.microsoft.com/de-de/powershell/module/exchange/import-exchangecertificate?view=exchange-ps
Zeile 636 sollte neu zum Beispiel so aussehen:
Import-ExchangeCertificate -FileData ([System.IO.File]::ReadAllBytes($CertPath)) -FriendlyName $SANAlias -Password $ImportPassword -PrivateKeyExportable:$true | Enable-ExchangeCertificate -Services „SMTP, IMAP, POP, IIS“ –force
Hallo,
ich muss mich leider wieder um uns Zertifikat kümmern, da mit ein das letzte ioS Update keinen Gefallen getan hat. Ich bin nach der tollen Anleitung los marschiert.
Aber leider ist nach erste drei Punkten schluss.
Der erste Unterschied ist das bei mir „Cached order has status invaild discarding, “ kommt und nicht vaild.
Ich hatte vorher ein eignes Zertifikat erstellt, auch nach einer sehr guten Anleitung von Franky. Leider will dieses Zertifikat nicht mehr mit neusten Update von Apple funtkionieren.
Das script läuft dann weiter und endet auch bei dem Fehler 400. Obwohl alles frei ist.
Ich hoffe einer kann mit den entscheidenen Tipp geben.
Vielen Dank
Muss ich vorher ein Zertifikat bei Let’s Encrypt erstellt haben?
Habs mit dem Video von Youtube hinbekommen.
https://www.youtube.com/watch?v=KkwWar5CiMg
Danke für die gute Anleitung. Funktioniert prächtig, nur die Aufgabe hat sich bei mir nicht erstellt.
Hat jemand die Möglichkeit, die Eigenschaften des entstandenen Tasks auszulesen? Dann erstelle ich den selbst.
Danke!
Habe es natürlich dann gleich selbst gefunden: WinACME hat, direkt als Administrator gestartet, eine Option („O“) für „T: (Re)create scheduled task“. Das hat auch gleich funktioniert. :)
Hallo, bekomme „detail“: „Fetching http://xxxxxxx/.well-known/acme-challenge/code: Timeout during connect (likely firewall problem)“
Fehler 400
Die Firewall lässt aber 80, 443 durch?
Hilfe?
Beste Grüße
Mislo
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
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?
hast du das hinbekommen mit dem „ungültigen“ Status ? wenn ja wie ?
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″
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
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.
Du bist mein Held!!!! 1000 Dank!
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?
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?
Heho,
… kennt denn keiner Certify? https://certifytheweb.com/
Sehr mächtig, kann alles was das Herz auch nur begehren kann und ist sehr zuverlässig.
HTH,
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?
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.
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?
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.
Liegt sicherlich am deutschen Windows Server. Statt –acl-fullcontrol „network service,administrators“ solltet ihr –acl-fullcontrol „Netzwerkdienst,Administratoren“ verwenden
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!?
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.
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.
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!
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 :)