Certificate Assistant: Neue Version

Gerade habe ich eine neue Version des Exchange Certificate Assistant hochgeladen. Die alte Version verwendet noch das Let’s Encrypt Protokoll ACMEv1, welches nicht mehr von Let’s Encrypt unterstützt wird.

Die neue Version 3 des Certificate Assistant verwendet nun das PowerShell Modul Posh-ACME, um automatisch Zertifikate für Exchange Server via Let’s Encrypt anzufordern. Posh-ACME ist ACMEv2 kompatibel und somit auch in der Lage Wildcard Zertifikate von Let’s Encrypt anzufordern. Der Certificate Assistant verwendet allerdings nach wie vor keine Wildcard Zertifikate, sondern SAN-Zertifikate, welche mittels HTTP-01 Challenge validiert werden. Der Vorteil von HTTP-01 ist, dass sich der komplette Prozess für Exchange Zertifikate automatisieren lässt und keine Anpassungen am DNS erforderlich sind. Es sind nur wenige Einstellungen im Script selbst zu definieren, der Rest läuft dann vollautomatisch.

Die aktuelle Certificate Assistant Version unterstützt die folgenden Exchange Server Versionen:

  • Exchange 2010 (PowerShell 5 erforderlich, PowerShell 5 ist nicht für SBS Server freigegeben)
  • Exchange 2013
  • Exchange 2016
  • Exchange 2019

Ich habe mal ein kleines Video aufgenommen welches den Certificate Assistant auf einem Exchange 2019 Server in Aktion zeigt:

Exchange Zertifikate Assistant kann hier runtergeladen werden:

Im ZIP Archiv findet sich jeweils ein Script je nach Exchange Version. Hier noch eine kleine Anleitung zur Benutzung.

Anleitung

Im Script finden sich ein paar grundlegende Einstellungen die zunächst konfiguriert werden müssen. Die folgenden drei Einstellungen müssen zwingend angepasst werden, die restlichen Einstellung sind optional:

image

Erforderliche Einstellungen

Mittels $LetsEncryptMode wird festgelegt, über welches Let’s Encrypt System die Zertifikate angefordert werden. “LE_Stage” ist das Testsystem, mit dem zunächst die Funktion des Scriptes getestet werden kann. Im Modus “LE_Stage” werden keine gültigen Zertifikate angefordert und es greifen keine Let’s Encrypt Limits. Der “LE_Stage”-Modus ist also ideal zum Testen, wenn erfolgreich ein Zertifikat ausgestellt wurde, kann das Script das Let’s Encrypt Poduktiv System verwenden um gültige Zertifikate anzufordern (LE_Prod).

$ContactMail ist für die Registrierung des Let’s Encrypt Kontos erforderlich. Hier muss eine gültige E-Mail Adresse angegeben werden. Das Let’s Encrypt  Konto wird, wenn nötig, automatisch vom Script erstellt.

$PFXPasswort legt das Passwort für das Zertifikat (PFX-Datei)  fest. Das Passwort ist erforderlich, wenn das Zertifikat auch auf anderen Servern installiert werden soll.

Optionale Einstellungen

$WriteConsoleLog steuert die Logausgabe, es wird immer ein Logfile im Certificate Assistant Verzeichnis geschrieben, mittels $WriteConsoleLog lässt sich nur die Ausgabe in der Konsole abschalten ($false), nicht aber das Logfile.

$DetermineExchangeFQDNs und $CustomFQDNs gehören zusammen. In der Standardeinstellung versucht das Script automatisch die erforderlichen Hostnamen für das Zertifikat zu ermitteln ($DetermineExchangeFQDNs  = $true). Wenn andere Hostnamen oder zusätzlichen DNS-Namen gewünscht oder erforderlich sind, kann $DetermineExchangeFQDNs auf den Wert $false gesetzt werden. In diesem Fall müssen dann alle DNS-Namen angegeben werden ($CustomFQDNs).

Die Einstellungen ab $SendMail sollten selbsterklärend sein. Certificate Assistant verschickt nach einem Durchlauf das Logfile per Mail.

Hinweise

Exchange Certificate Assistant ist darauf ausgelegt direkt auf einem Exchange Server ausgeführt zu werden. Der Exchange Server selbst muss aus dem Internet unter den entsprechenden Hostnamen auf Port 80 (http) und Port 443 (https) erreichbar sein. Andernfalls schlägt die Validierung fehl und es kann kein Zertifikat angefordert werden.

Eine öffentliche CA wie Let’s Encrypt kann keine Zertifikate für “nicht öffentliche” Domänen ausstellen. Es können also keine Zertifikate mit Hostnamen wie “server1.domain.local” angefordert werden. Die Exchange Virtual Directorys müssen also auf öffentliche Hostnamen konfiguriert werden. Eine entsprechende Konfiguration ist hier beschrieben:

Bei Problemen oder Fehlern mit diesem Script kann gerne das Forum genutzt werden. Bitte in diesem Fall immer das Logfile anhängen und darauf achten, dass keine sensiblen Informationen im Logfile stehen (also bitte entsprechend löschen).

25 Kommentare zu “Certificate Assistant: Neue Version”

  1. Vielen Dank!

    Der erste Testrun lief problemlos durch. Hat mich nur etwas verwundert, dass das ungültige Test Zertifikat dann doch im ECP eingetragen wurde. War zwar schnell wieder geändert, nachdem die Funktion des Zertifikates gegeben war, hat mich aber trotzdem kurz verwirrt :)

    Danke für deine Mühen!

  2. Hi,

    leider ein Problem bei Exchange 2010 (SBS2011).

    PS C:\Windows\system32> C:\Users\admin\Desktop\CertificateAssistant_v3_EX2010.ps1
    03.12.2019 09:30:54 – System – Info – Geting system parameters
    03.12.2019 09:30:54 – System – Info – Certificate Assistant Exchange 2010 Version
    03.12.2019 09:30:54 – System – Info – PowerShell Version: 5.1.14409.1018 OSVersion: 6.1.7601.65536
    03.12.2019 09:30:54 – Check Posh-ACME – Info – Check if Module installed
    03.12.2019 09:30:54 – Load Posh-ACME – Info – Posh-ACME is installed, try to load it
    03.12.2019 09:30:54 – Load Posh-ACME – Info – Module Import was successfull, PoshACMEVersion 3.11.0
    03.12.2019 09:30:54 – Load Exchange SnapIns – Info – Try to load Exchange SnapIns
    03.12.2019 09:30:54 – Load Exchange SnapIns – Info – Sucessfully loaded Exchange SnapIns
    03.12.2019 09:30:54 – IIS – Info – Trying to create .Well-Known Directory
    03.12.2019 09:30:55 – IIS – Info – Well-Known Folder already exists, skipping
    03.12.2019 09:30:55 – IIS – Warning – Mime Type was not added to Well-Known folder, maybe it was already added
    03.12.2019 09:30:55 – IIS – Info – Changing Let’s Encrypt IIS directory to http
    03.12.2019 09:30:55 – IIS – Info – Successfully changed Let’s Encrypt IIS directory to http
    03.12.2019 09:30:55 – IIS – Info – Checking Let’s Encrypt IIS directory to accept validation by http request
    03.12.2019 09:30:55 – IIS – Info – .well-known directory accepts http
    03.12.2019 09:30:55 – Custom FQDNs – Info – Using Custom FQDNs is configured
    03.12.2019 09:30:55 – LE System – Info – Setting LE Mode
    03.12.2019 09:30:56 – LE System – Info – Setting LE Mode to PRODUCTION MODE (LIVE SYSTEM)
    03.12.2019 09:30:56 – LE System – Info – Checking for existing LE Account
    03.12.2019 09:30:56 – LE System – Info – Found a existing LE Account
    03.12.2019 09:30:56 – LE Certificate – Info – Trying to create a new order for a certificate
    03.12.2019 09:30:56 – LE Certificate – Info – Successfully ordered certificate
    03.12.2019 09:30:56 – LE System – Info – Creating Autorisation files for LE verification
    03.12.2019 09:30:57 – LE System – ERROR – Can’t create Autorisation files for LE verification
    03.12.2019 09:30:57 – LE System – Info – Asking LE to verify the order
    03.12.2019 09:30:57 – LE System – Info – Successfully informed LE to verify the order
    03.12.2019 09:30:57 – LE System – INFO – Let’s give LE some time to validate (1 min)
    03.12.2019 09:31:17 – LE System – INFO – Time to wake up, need coffee!
    03.12.2019 09:31:17 – LE System – INFO – Let’s check the authorization
    03.12.2019 09:31:17 – LE System – INFO – Authorization for mail.MyDomainName.com is valid
    03.12.2019 09:31:17 – LE System – INFO – Let’s refresh the order
    03.12.2019 09:31:17 – LE System – INFO – Let’s check if order is ready
    03.12.2019 09:31:17 – LE System – ERROR – Order is NOT ready

    End of script. Was passiert hier falsch? Hab 60 Sek Validierung auf 20 Sek eingestellt, aber mit 60 Sek bringts auch keinen Mehr-Effekt, also selber Fehler.

    Bitte um deine geschätzte Unterstützung Frank!
    lg aus Wien

  3. Habs auch getestet, danke für das Script aber:

    Auf Exchange 2019 der gleiche Fehler wie oben:
    LE System – ERROR – Order is NOT ready

    1. Hallo,
      lasst uns doch solche Probleme im Forum diskutieren. :-)
      Sind die Server per Port 80 und 443 aus dem Internet erreichbar? Könnt ihr im Forum das komplette Log posten?
      Besten Dank und Gruß,

      Frank

  4. Einmal mehr besten Dank für eine Arbeit Frank. Damit wird das Leben als Admin wieder etwas leichter!
    Heute ergab sich die Gelegenheit, die neue Version zu testen und dabei gab es 2 „Fehler“.

    1) bei der 1. Ausführung, gab es eine Meldung, dass .NET 4.7.1 installiert sein muss, sonst gibt es möglich Fehler (installiert war 4.6.2). Das Script gab tatsächlich eine Fehlermeldung:

    03.12.2019 18:52:53;LE System;INFO;Order is ready;
    03.12.2019 18:52:53;LE System;INFO;Let’s get the certificate;
    03.12.2019 18:52:54;LE System;ERROR;Getting certificate was not successfull;Der Typ [Org.BouncyCastle.Security.SecureRandom] kann nicht gefunden werden. Stellen Sie sicher, dass die Assembly, die diesen Typ enthält, geladen wird.

    Eigentlich ein klarer Fall, sobald die Version .NET 4.7.1 installiert war (+ Neustart) konnte das Zertifikat erfolgreich mit dem Script installiert werden.

    2) um zu testen, verbinde ich immer über WAN mit der externe URL, um mir danach das Zertifikat kurz anzusehen. Diesmal auch mit Waterfox die URL https://server.kunde.ch/owa geöffnet aber das wurde als unsicher gemeldet. Die Seite konnte nicht angezeigt werden. Dasselbe mit Google Chrome (beide neuste Version). IE11 & Edge hatten dieses Problem nicht und es war nur bei dieser Server. Die exakte Fehlermeldung ist leider nicht auffindbar, meldete jedoch die Verwendung von unsichere Protokolle. Daraufhin habe ich „IIS Crypto“ gestartet und die aktive Protokolle gemäss Best Practice angepasst. Ein Neustart später hat die Verbindung wieder korrekt funktioniert, mit allen Browsern.
    Warum das diesmal passierte ist noch unklar. Eventuell hat sich bei Lets Encrypt etwas verändert, das muss ich noch abklären. IIS Crypto werde ich den nächsten Monaten sowieso noch viel einsetzen, Server Hardening ist angesagt bei alle Kunden-Server.

    Grüsse
    Eric

    1. Hallo Eric,

      ich bekomme den selben Fehler mit „Org.BouncyCastle.Security.SecureRandom“

      Sowohl unter Exchange 2010 (Server2008R2) und Exchange 2013 (Server 2012R2).
      Beide haben .NET 4.7.2 installiert.
      Noch etwas anderes geändert außer .NET?

      1. Hallo Benjamin

        Nein, bei mir genügte es .NET 4.7.1 zu installieren (von 4.6.2) und danach konnte das Script alle Aufgaben fehlerfrei ausführen. Hast du die Server neu gestartet und ist die Version 4.7.2 tatsächlich drauf?
        Hier gibt es noch 2-3 Sätze mehr zum Thema (English): https://github.com/rmbolger/Posh-ACME/issues/56#issuecomment-401885623

        Umgebung: Windows Server 2016 1607 Build 14393.2972, Exchange 2016 CU8 (ja, ich weiss, es gibt schon CU14 aber eine Freigabe des Kunden lässt auf sich warten).

        Gruss
        Eric

        1. Hallo Eric,

          Danke für deine Antwort

          Den Githup Post hatte ich auch schon gefunden ;-)
          Laut Build Number 461814 ist es .Net 4.7.2
          Server wurde auch neu gestartet.

          Gruß
          Benjamin

  5. Hallo Frank,

    vorerst danke für das Skript. Schon das letzte hilft sehr!
    Du schreibst, wir sollen das im Forum besprechen.

    Könntest du den Forenlink hier posten, in dem das besprochen wird?
    Im Forum gibts Exchange 2010/2013/2016/2019 Kategorien, in denen das alles reinpasst.

    Aber vermutlich ist der obige Fehler nur einmal zu behebung bei allen Systemen funktionierts dann gleich.

    Port 80+443 sind aus dem Internet erreichbar. Es wird nur ein Domainname zertifiziert und der ist bei mxtoolbox auch vorhanden mit korrekter IP-Adresse und offenen Ports.
    Habe die betreffende Zeile auch auf die notwendige Domain umgeändert, aber derselbe Fehler.

    Bitte um Link zum Thread dazu.

  6. Eine kurze Frage, ich möchte das Skript auf einem Exchange 2013 SP1 ausführen.
    Kann ich hier Powershell 5 installieren oder ist das erst auf einem aktuelleren Patchstand möglich?

  7. Hi Frank,

    erstmal danke für deine Arbeit und das Skript :-), echt eine coole Sache!
    Noch eine Frage, im Task Scheduler wird das Skript jetzt einfach ohne Switch (-renew:$true) aufgerufen oder?

    Danke!
    SG
    Sebastian

  8. Hallo Frank,

    auf dem ersten System Exch2019 eingerichtet, läuft, gibt es eine Möglichkeit die verbleibenden Tage vor dem renew zu beeinflussen? Hintergrund ist noch genügend Zeit zu haben, wenn das mal schief geht, aktuell Monitore ich die verbleibenden Tage und werde aktiv benachrichtigt, wenn in meinem Fall dir Restzeit unter 10 Tage fällt, um so eine gute Woche als Reserve zu haben, hatte ich den Renew immer bei 12 Tagen, wie läuft das jetzt, wann wird erneuert, beeinflussbar ?

  9. Hallo und danke für das Skript,

    ich bekomme leider nur ein ungültiges Zertifikat ausgestellt:
    Von einer Zertifizierungsstelle signiertes Zertifikat
    Aussteller: CN=Fake LE Intermediate X1
    Exchange 2016 CU14 auf Server 2016

  10. Hallo Frank,
    ich bitte um Hilfe:
    SBS2011 / EXC2010 mit aktuellem Script.
    1.) 13.12.2019 20:49:55 – LE System – ERROR – Can’t create Autorisation files for LE verification
    2.) 13.12.2019 20:50:58 – LE System – ERROR – Order is NOT ready

    Vielleicht gibt es einen Zusammenhang zwischen beiden Fehlermeldungen?

Schreibe einen Kommentar

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