Certificate Assistant: Jetzt auch für Exchange 2010 und Server 2008 R2

Jetzt kann ich Vollzug melden, die aktuelle Version des Certificate Assistant für Let’s Encrypüt unterstützt nun auch Exchange 2010 und Server 2008 R2. Ich habe den Download noch einmal aktualisiert und es sind nun 3 Versionen des Scripts enthalten:

Certificate Assistant: Jetzt auch für Exchange 2010 und Server 2008 R2

Somit werden nun die folgenden Betriebssysteme unterstützt:

  • Windows Server 2008 R2
  • Windows Server 2012 R2
  • Windows Server 2016

Ich habe das Script mit den jeweils aktuellen Exchange Versionen getestet:

  • Exchange 2016 CU8
  • Exchange 2013 CU 19
  • Exchange 2010 SP3 UR 19

Die Exchange 2010 Version des Scripts benötigt als Voraussetzung das Windows Management Framework 4 und .NET Framework 4.5.2. Diese beiden Komponenten müssen installiert sein, bevor das Script ausgeführt wird. Die Download Links für die Voraussetzungen finden sich im Ordner “Exchange 2010” in der Datei README.txt des Archivs.

Noch ein kleiner Hinweis an dieser Stelle:

Öffentliche CAs wie Let’s Encrypt können und dürfen keine Zertifikate für “private” FQDNs ausstellen. FQDNs wie “srv1.domain.local” oder “exchange.domain.intern” können also nicht auf einem öffentlichen Zertifikat aufgenommen werden. Das Script versucht in der Standardeinstellung die erforderlichen FQDNs für das Zertifikat aus den Virtual Directorys des Exchange Servers zu ermitteln (InternalURL und ExternalURL). Damit das Zertifikat von Let’s Encrypt ausgestellt werden kann, muss der Exchange Server unter allen konfigurierten FQDNs aus dem Internet erreichbar sein. Wenn dies nicht der Fall ist, lässt sich im Script die automatische Ermittlung abschalten und eigene FQDNs festlegen.

Mit dem Small Business Server 2011 habe ich das Script nicht testen können.

Den Download Link habe ich entsprechend aktualisiert:

Der Task zu Erneuerung des Zertifikats muss manuell erstellt werden. Hier das Beispiel für Server 2008 R2:

Certificate Assistant: Jetzt auch für Exchange 2010 und Server 2008 R2

Als Trigger könnten zum Beispiel alle 2 Monate ausgewählt werden, so bleibt genug Zeit zum manuellen Eingreifen falls etwas schief geht:

Certificate Assistant: Jetzt auch für Exchange 2010 und Server 2008 R2

Als Aktion wie gehabt den Pfad zur PowerShell angeben und als Argument den Pfad zum Script:

Certificate Assistant: Jetzt auch für Exchange 2010 und Server 2008 R2

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

Wenn es Probleme oder Fehler mit dem Script gibt, dann schickt mir bitte das komplette Logfile per Mail. Ich versuche gerne zu helfen, kann dies aber nur mit dem kompletten Log. Daher auch bitte nicht das Logfile kürzen oder Teile davon entfernen.

46 Replies to “Certificate Assistant: Jetzt auch für Exchange 2010 und Server 2008 R2”

  1. Hallo Wolfgang,
    Windows Server 2012 sollte problemlos mit Exchange 2013 und Exchange 2016 funktionieren, es muss allerdings mindestens die PowerShell 4 und NET 4.5 installiert sein.
    Gruß,
    Frank

  2. Hallo,
    ich teste es gerade auf einem SBS2011 (die alte Version v1 des Scripts läuft).
    Aktuell bekomme ich einen Fehler:
    11.03.2018 13:54:19;Certificate;Error;Failed to submit the certificate for signing;Access to the path ‚C:\ProgramData\ACMESharp\sysVault\45-KEYPM\5f994338-dddf-40d7-8ec3-83a5a96a396f-key.pem‘ is denied.

    Der User hat ein gültiges EFS-Zertifikat.

  3. mittlerweile läuft das Script (war scheinbar doch noch ein EFS Problem)
    Danke.

    Was passiert mit den „alten“ Zertifikaten, werden die gelöscht, oder muss ich da manuell ran?

  4. Hallo Andi,
    hast du noch ein ungültiges EFS Zertifikat gefunden?
    Die vorhandenen Zertifikate werden nicht durch das Script gelöscht. Hier musst du manuell eingreifen.
    Gruß, Frank

  5. Hallo Frank, mein EFS-Recovery Zertifikat war abgelaufen.
    Hab ein neues ausgestellt und dann lief es.

    Allerdings erhalte ich beim Aufruf der Seite eine Warnmeldung:
    DLG_FLAGS_SEC_CERT_CN_INVALID

  6. Das Warnmeldungsproblem ist auch gelöst, Das Problem lag vor dem Monitor. :-) hatte noch eine altenUrl aufgerufen, die nicht mehr in der Zertifikatskonfig ist.

  7. Hallo Frank,

    danke für Dein Engagement, was Exchange und LE angeht. Bisher verwende ich CertificateAssistant v1 mit Exchange 2010 unter Srv 2008 R2 – was auch funktioniert (sollte es nicht?).

    Die neue Version möchte aber nicht so recht – egal ob ich die bestehenden Zertifikate belasse oder bei Null starte. ACMESharp scheitert an folgendem Punkt:

    13.03.2018 11:34:30;Certificate;Info;Using Cert13032xxxxxxx-2 as certificates CN;
    13.03.2018 11:34:30;Certificate;Info;Certificate creation successfully, Alias SAN130320181134;
    13.03.2018 11:34:30;Certificate;Info;Try to submit the certificate to Let’s Encrypt;
    13.03.2018 11:34:30;Certificate;Error;Failed to submit the certificate for signing;Access to the path ‚C:\ProgramData\ACMESharp\sysVault\45-KEYPM\b18ba6c7-2505-4dbc-b74c-043f20(…)-key.pem‘ is denied.

    Es gibt aber kein Problem mit den Rechten (habe ich geprüft), sondern die Datei „b18ba6c7-2505-4dbc-b74c-043f20(…)-key.pem“ existiert schlicht nicht.

    Mache ich etwas falsch? Wäre dankbar für einen Hinweis.

    Gruß
    Jan

  8. Nachtrag: es handelt sich um Windows Server 2008 R2 mit Windows Management Framework 5.1 und .NET Framework 4.7.1, aber ich nehme an neuer als gefordert ist in Ordnung …

  9. Hallo Frank,

    Danke für dieses Skript.
    Am Anfang lief alles problemlos durch, aber es failed anscheinend bei der Challenge.
    Wie kann man diesen Fehler beheben?

    13.03.2018 19:22:13;LE Challange;Info;Try to submit challenge;
    13.03.2018 19:22:14;LE Challange;Info;Submitted challenge for Alias Cert13032018xxxx-1;
    13.03.2018 19:22:14;LE Challange;Info;Try to submit challenge;
    13.03.2018 19:22:15;LE Challange;Info;Updated Identifier for Alias Cert13032018xxxx-1;
    13.03.2018 19:22:15;Certificate;Info;Try to create the certificate;
    13.03.2018 19:22:15;Certificate;Info;Using Cert13032018xxxx-1 as certificates CN;
    13.03.2018 19:22:15;Certificate;Info;Certificate creation successfully, Alias SAN13032018xxxx;
    13.03.2018 19:22:15;Certificate;Info;Try to submit the certificate to Let’s Encrypt;
    13.03.2018 19:22:21;Certificate;Error;Failed to submit the certificate for signing;Unexpected error
    +Response from server:
    + Code: Forbidden
    + Content: {
    „type“: „urn:acme:error:unauthorized“,
    „detail“: „Error creating new cert :: authorizations for these names not found or expired: mail.xxxx.at“,
    „status“: 403
    }

    Gruß
    Hölli

  10. Hallo Frank,

    danke für den Hinweis, das ist mir irgendwie durch die Lappen gegangen.

    Gruß,
    Jan

  11. Hallo alle Zusammen.
    Zuerst einmal Vielen Dank für die vielen Hilfestellungen und die damit verbundene Arbeit von Frank :)
    Wir haben einen Server 2016 und einen Exchange 2016 (virtuell) als Ersatz für den betagten SBS2011 aufgesetzt. Soweit klappt auch alles intern. (nicht zuletzt durch diese Seite hier).
    Lediglich bei der Anbindung der Smartphones per EAS gibt es Probleme. Hier liegt es wohl an dem selbst ausgestellten Zertifikat. Beim SBS war das problemlos, nun scheint das aber nicht zu funktionieren.
    Nun habe ich versucht mit Hilfe des certificate-assistant ein Lets Encrypt einzubinden. Hier bekomme ich den selben Fehler wie schon weiter oben beschrieben .

    19.03.2018 13:44:17 – Certificate – Info – Certificate creation successfully, Alias SANXXXXXXXXXXXXX
    19.03.2018 13:44:17 – Certificate – Info – Try to submit the certificate to Let’s Encrypt
    19.03.2018 13:44:20 – Certificate – Error – Failed to submit the certificate for signing
    Im Log-File steht weiterhin.

    Unexpected error
    +Response from server:
    + Code: Forbidden
    + Content: {
    „type“: „urn:acme:error:unauthorized“,
    „detail“: „Error creating new cert :: authorizations for these names not found or expired: autodiscover.domain.de, remote.domain.de“,
    „status“: 403
    }
    Ich vermute ( wegen dem 403) das es ein Zugriffsproblem gibt. Stehe aber auf der Leitung an welcher Stelle.
    Evtl. kann mir jemand einen Tipp geben .

    Danke

    Oliver

  12. Hallo Zusammen,
    wir versuchen es auch auf einem SBS 2011, bekommen dabei aber folgende Fehlermeldung:
    Certificate;Error;Failed to submit the certificate for signing;Error resolving type specified in JSON ‚ACMESharp.PKI.CsrDetails, ACMESharp‘. Path ‚$type‘, line 2, position 48.

    Trotz intensiver Recherche habe ich keine Idee woran es denn liegen könnte, ist noch jemand über diese Fehlermeldung gestolpert? In einem anderen Blog habe ich den Hinweis gefunden, dass es mit einer elevated Powershell nicht passieren soll, hat in unserem Fall aber nicht geholfen.

    VG
    Jan

  13. Hallo Frank,
    großartige Arbeit, vielen Dank dafür!
    Derzeit ist es ja so, dass zur Validierung der ACME Challenge für kurze Zeit ein HTTP Server auf Port 80 aufgemacht wird, der unter dem zu validierenden Domainname auch erreichbar sein muss. Ich müsste also bei scriptbasierter automatischer Erneuerung der Zertifikate diesen Port dauerhaft offen lassen, was ich nicht so schick finde. Wird es zukünftig möglich auch mit Deinem Script möglich sein, die Challenge dauerhaft als TXT im DNS zu hinterlegen, damit das Script das Zertifikat ohne Port 80 erneuern kann?

    Gruß
    Dennis

  14. Hallo Frank,
    wollte mal nachfragen ob es bereits eine Lösung zu meinem Fehler gibt?

    Gruß,
    Hölli

  15. Hallo Frank
    Ich bekomme den gleichen Fehler wie Oliver.
    Ich benutze die aktuelle Version
    Kannst du mir sagen wie ich den Fehler beseitigen kann?
    Certificate;Error;Failed to submit the certificate for signing;Unexpected error
    +Response from server:
    + Code: Forbidden
    + Content: {
    „type“: „urn:acme:error:unauthorized“,
    „detail“: „Error creating new cert :: authorizations for these names not found or expired: autodiscover.tobien.net, outlook.tobien.net“,
    „status“: 403
    }
    Danke
    Marc

  16. Moin Franky,

    evtl. kannst du das mal nachstellen und evtl. auch eine Lösung finden.

    Habe nach dem Update auf das neuste CU auf dem Exchange 2016 TLS 1.0 und 1.1 deaktiert.
    Eben wollte ich auf dein neustes Script updaten. Aber ACMESharp ließ sich nicht installieren, da keine Verbindung zur Powershell Gallery hergestellt werden konnte.
    Habe TLS 1.1 und 1.0 wieder aktiviert. Danach klappt die Installation des neusten Moduls

  17. Hallo Frank,

    ich habe immer noch das Problem, dass das Script auf einem Exchange 2016 (auf Server 2016) die folgende Fehlermeldung wirft:

    16.04.2018 12:55:24;Check Vault;Info;Lets check if exists a vault;
    16.04.2018 12:55:24;Check Vault;Info;Vault found;
    16.04.2018 12:55:24;Check Registration;Info;Lets check if exists a LE registration;
    16.04.2018 12:55:24;Check Registration;Warning;No Registration found, try to create one;No registrations found
    16.04.2018 12:55:26;Check Registration;Error;Can’t create registration, exiting script;Unexpected error
    +Response from server:
    + Code: BadRequest
    + Content: {
    „type“: „urn:acme:error:invalidEmail“,
    „detail“: „Error creating new registration :: DNS problem: NXDOMAIN looking up MX for yourdomain.tld“,
    „status“: 400
    }

    Hast du eine Idee, was da schief läuft?

    Was mich irritiert ist „yourdomain.tld“. Sollte da nicht die echte Domain in der Fehlermeldung stehen?

    Die DNS-Namen des Servers werden laut Log korrekt erkannt.

  18. @Jörn

    werden alle korrekt erkannt, oder liegt evtl. doch noch eine .local vor?
    Du könntest in dem Script auch die FQDN manuells eintragen und den Schalter passend setzen.

    Mfg

    Stephan

  19. ich sehe gerade, in dem Script musst du eine gültige E-Mailadresse hinterlegen.
    Das scheint auch nicht erledigt worden zu sein.

  20. Hallo Stephan,

    danke für den Hinweis. Das hatte ich dann aufgrund deines ersten Kommentars auch gesehen. War mir neu, da es in der alten Version des Scriptes nicht notwendig war. Nachdem ich jetzt dieses Problem gelöst habe, bin ich aber in das Problem mit dem abgelaufenen EFS-Zertifikat gelaufen. Ich habe das Zertifikat gem. der verlinkten Anleitung dann gelöscht und wollte einen neuen „Datenwiederherstellungs-Agenten“ erstellen. Hierbei bekomme ich jetzt allerdings die folgende Fehlermeldung: „Es kann kein Datenwiederherstellungs-Agent erstellt werden. Die angeforderte Zertifikatsvorlage wird von dieser Zertifizierungsstelle (CA) nicht unterstützt“.

    Wenn ich versuche das Certificate-Assistent-Script auszuführen bekomme ich jetzt folgende Fehlermeldung:

    16.04.2018 13:53:12;Certificate;Error;Failed to submit the certificate for signing;Unexpected error
    +Response from server:
    + Code: Forbidden
    + Content: {
    „type“: „urn:acme:error:unauthorized“,
    „detail“: „Error creating new cert :: authorizations for these names not found or expired: autodiscover.jergler.de, gate.jergler.de“,
    „status“: 403
    }

    Ich muss dazu sagen, dass der Windows Server 2016 die Rolle des Domänencontrollers von einem bisherigen Windows Server 2012 übernommen hat. Evtl. sind hier noch ein paar Anpassungen notwendig. Leider bin ich momentan ziemlich ratlos, was zu tun ist. Hat jemand von euch dieses Problem schon einmal gehabt?

  21. Habe eben noch mal dein Log angesehen…
    die DNS Namen müssen auf 80 auf deinen Server auflösen können. ich komme nur auch Port 443 auf dein Autodiscover, hast du dir das mal angesehen.

  22. Stephan: Vielen Dank! Jetzt funktionierts! Allerdings bin ich mir nicht sicher, ob’s wirklich am Port 80 lag, oder ob’s nur Zufall war und ich hätte langer warten müssen, bis das neue EFS-Cert aktiv wurde. Wie auch immer, das Cert ist jetzt erfolgreich installiert. Danke für deine Hilfe!

  23. Dein Problem scheint nicht an EFS gelegen zu haben ;-)
    Jetzt kann ich im Portscan ja sehen, das Port 80 geöffnet ist, war vorher dicht. Der muss auch auf bleiben, sonst funktioniert die automatische Verlängerung nicht. (Musst du auch manuell als Task anlegen).

    Aber Franky wollte ja mal schauen, ob er das auf DNS Validierung ändert… währe ein Traum :)

  24. Seit dem ich das LE Zertifikat verwende ist am Exchange Server die Ereignisanzeige überschwemmt mit folgendem Fehler:

    Ebene: Fehler
    Quelle: Schannel
    Ereignis-ID: 36887
    Es wurde eine schwerwiegende Warnung empfangen: 46.

    Fehler tritt spätestens alle 5 Minuten auf.

    Hat diesbezüglich jemand eine Lösung?

    Danke im Voraus!

  25. Hi Franky:
    I try this CertificateAssistant_v2_EX2010.ps1 with a Error,Pls help.Thank u very much!
    TimeStamp;ScriptSection;Type;Message;ErrorDetails
    08.05.2018 14:48:07;System;Info;Geting system parameters;
    08.05.2018 14:48:07;System;Info;Certificate Assistant Exchange 2016 Version;
    08.05.2018 14:48:07;System;Info;PowerShell Version: 5.0.10586.117 OSVersion: 6.1.7601.65536;
    08.05.2018 14:48:07;Load Exchange SnapIns;Info;Try to load Exchange SnapIns;
    08.05.2018 14:48:09;Load Exchange SnapIns;Error;Failed to load Exchange SnapIns, exiting script;
    08.05.2018 14:55:25;System;Info;Geting system parameters;
    08.05.2018 14:55:25;System;Info;Certificate Assistant Exchange 2016 Version;
    08.05.2018 14:55:25;System;Info;PowerShell Version: 5.0.10586.117 OSVersion: 6.1.7601.65536;
    08.05.2018 14:55:25;Load Exchange SnapIns;Info;Try to load Exchange SnapIns;
    08.05.2018 14:55:25;Load Exchange SnapIns;Error;Failed to load Exchange SnapIns, exiting script;

  26. Guten Tag Zusammen,
    Ich habe die Anleitung befolgt und bin nach einigen Fehler zu diesem letzendlichen Fehler gekommen.

    Zuerst hatte ich den Fehler bzgl. der Fehlenden Email diese habe ich im Script ergänzt und nun komme ich hier nicht weiter. Port 80 ist geöffnet. und sollte auch richtig sein. (Denke ich)

    12.06.2018 12:59:57;Certificate;Error;Failed to submit the certificate for signing;Unexpected error
    +Response from server:
    + Code: Forbidden
    + Content: {
    „type“: „urn:acme:error:unauthorized“,
    „detail“: „Error creating new cert :: authorizations for these names not found or expired: autodiscover.walraven-gmbh.de, outlook.int.walraven-gmbh.de, remote.walraven-gmbh.de“,
    „status“: 403
    }

  27. Zusatz:

    Wir haben mehrere Feste IP’s und eine Feste wird nur für den Mailserver genutzt. Und wird dann auch dorthin aufgelöst. Dies ist aber nicht die IP mit der wir sonst im Internet surfen. Allerdings ist der SMTP Server Port 25 dorthin aufgelöst. Genauso wie der Port 443 dazu jetzt auch noch der Port 80 damit sollte alle gegeben sein? Habe ich einen Denkfehler?

  28. Hallo Franky,

    kannst Du mir sagen, ob der Certificate Assistant auch funktioniert, wenn man Exchange (2010) im Hybrid-Modus für Office 365 eingerichtet und im Hybrid-Assistenten das aktuell gültige LE-Zertifikat ausgewählt hat?

    Danke & Gruß
    Jan

  29. Hallo zusammen

    Zuerst mal danke Franky für dieses großartige Script, es läuft bei mir mit Windows Server 2012 und Exchange 2010/2013 sowie auf Windows Server 2016 und Exchange 2016 ohne Probleme.

    An jene die noch einen SBS2011 im Einsatz haben: Wie habt ihr das Script zum Laufen bekommen? Voraussetzung ist ja das Windows Management Framework 4, welches auf dem SBS2011 ja nicht installiert werden sollte (siehe https://blogs.msdn.microsoft.com/powershell/2013/10/24/windows-management-framework-4-0-is-now-available).

    Danke und LG
    Manuel

  30. Hallo ich will das Script auf einem 2008r2 mit Exchange 2010 nutzen.
    Das Script läuft soweit erstmal bleibt aber dann mit der Meldung

    30 Sekunden warten…
    Prüfe ob die DNS-Namen validiert wurden…
    Update Alias: Cert010820180754-1
    Fehler: Validierung für Alias Cert010820180754-1 fehlgeschlagen

    stehen.

    DNS Einträge (lokal splitbrain) müßten stimmen die Ports 80 und 443 sind geforwardet.

    Beim Forschen habe ich hier Beiträge gefunden die ähnliche oder gleiche Fehler hatten.

    Allerdings komme ich mit den dort geschilderten Problemlösungen nicht klar.

    Hat jemand einen Tipp für mich?

    MfG RO

  31. 1. Spitzen Script – Super Arbeit Franky!
    2. Währe es möglich das Renew-Script so anzupassen das vor dem Renew die Windows-Firewall Port 80 aufmacht und hinterher wieder zu? Speziell die SBS 2011 werden doch laut Virenscanner sehr häufig auf IIS-Fehler abgegrast, währe nice, wenn man das vermeiden könnte :-) (hab’s probiert, aber irgendwie will das nicht so wie gewünscht)
    Gruß – Meik

  32. Hallo Franky,
    auch ich danke für das Script, funktioniert bisher in allen getesteten Umgebungen einwandfrei.

    @Meik:
    Gute Idee!
    Geht auf einem alten SBS zum Beispiel mit diesen Commands:
    Regel hinzufügen:
    netsh advfirewall firewall add rule name=HTTP dir=in action=allow protocol=TCP localport=80

    Regel löschen:
    netsh advfirewall firewall delete rule name=HTTP

    Grüße,
    Achim

  33. Hallo Franky,

    ich teste gerade mit dem SBS 2011.
    MUß dfas ACME-Sharp Modul aktualisiert werden auf die Version 0.9.1.326?

    Grüße

    Karin

  34. Folgende Problematik stellte sich mir nach dem deaktivieren von TLS1.0 und 1.1:
    Die Powershell konnte keine HTTPS-Verbindung mehr aufbauen, ein Aufruf von z.B. New-ACMEIdentifiert führte zur Fehlermeldung:
    „Die zugrunde liegende Verbindung wurde geschlossen. Unbekannter Fehler beim empfangen.“

    Die Lösung fand sich hier auf dieser Seite unter https://www.frankysweb.de/powershell-es-konnte-kein-geschuetzter-ssltls-kanal-erstellt-werden/

    Nach Eingabe von:
    $AllProtocols = [System.Net.SecurityProtocolType]’Tls12′
    [System.Net.ServicePointManager]::SecurityProtocol = $AllProtocols
    direkt in die Powershell lief der Skript wieder durch.

    Es werden zwar nicht mehr viele mit 2008er Server arbeiten aber eventuell hilft es ja dem einen oder anderen.

    P.S. Danke für diesen genialen Skript!!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.