Hallo!
Das bisherige hat immer super funktioniert.
Das neue Skript sieht sehr angenehm aus mit der Vergabe der Variablen am Anfang.
Leider produziert es einen Fehler.
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
Port 80+443 ist extern erreichbar.
Bei einem anderen Exchange-Server 2010 funktioniert das Skript ebenso nicht und bleibt bei dem Teil hängen.
03.12.2019 09:30:57 – LE System – ERROR – Can’t create Autorisation files for LE verification
Ist im Skript mit dieser Prozedur drin:
try {
$auths = $LEOrder | Get-PAAuthorizations
$PublishAuths = $auths | Select @{L='Url';E={"http://$($_.fqdn)/.well-known/acme-challenge/$($_.HTTP01Token)"}},@{L='Filename';E={$($_.HTTP01Token)}},@{L='Body';E={Get-KeyAuthorization $_.HTTP01Token (Get-PAAccount)}}
foreach ($PublishAuth in $PublishAuths) {
$filename = $AcmeFolder + "\" + $PublishAuth.Filename
$authfile = out-file $filename -InputObject $PublishAuth.Body -Encoding ASCII
#Write-ACMELog "LE System" "Info" "Successfully created authorisation file: $filename"
}
}
catch {
$ErrorDetails = $_.Exception.Message
Write-ACMELog "LE System" "ERROR" "Can't create Autorisation files for LE verification" "$ErrorDetails"
}
die URL dürfte passen bei PublishAuths weil die Änderung auf den eigentlichen Domainnamen bringt denselben Fehler.
Vielleicht stimmt da was mit der URL nicht am Ende oder mit dem Token?
Servus,
kannst du mal bitte die Ausgabe von folgenden Befehl schicken?
get-paorder | Get-PAAuthorizations
Gruß,
Frank
Hier meine Ausgabe:
[PS] C:\Windows\system32>get-paorder | Get-PAAuthorizations
fqdn status Expires DNS01Status HTTP01Status
---- ------ ------- ----------- ------------
autodiscover.pcspezialist-regensburg.de invalid 11.12.2019 08:09:13 invalid invalid
mail.pcspezialist-regensburg.de valid 09.01.2020 10:19:45 pending valid
[PS] C:\Windows\system32>
Hi!
Habs lösen können!
Hatte (glaube ich) nichts mit Franks Skript zu tun. Warum auch immer, wird eine web.config Datei im well-known Ordner angelegt, sobald das Skript ausgeführt wird. Im Internet steht etwas dazu wegen einem Update von .Net3.5 und .Net4.0
http://127.0.0.1/.well-known/acme-challenge/
Kam bei mir
Insofern Notepad als Administrator gestartet, die web.config reingeladen und den Teil einfach rausgelöscht:
<mimeMap fileExtension="." mimeType="text/json" />
LÖSCHEN und abspeichern WÄHREND das Skript läuft und gerade die Domain(s) validiert. Dann ist der Zugriff auf die well-known-Dateien im Ordner möglich, es kann erfolgreich validiert werden und es funktioniert.
Testweise habe ich danach das Skript erneut aufgerufen OHNE Änderung der web.config währenddessen und wieder wie vorher: Validierung fehlgeschlagen und ich komme nicht auf die Dateien, sondern erhalte einen Fehler 500.
Entweder löst das dein Skript aus Frank oder beim Erstellen der Dateien schreibt sich die web.config um.
Hat bei mir das Problem gelöst. Ich kam darauf, weils bei EINEM anderen Kunden-SBS2011 funktioniert hat und so sah ich, dass es nicht am Skript liegen kann.
Hilft das den anderen vielleicht auch etwas?
@roman-edv
Servus Roman,
Dein Post ist Gold wert! Den Mimetype "." setze ich ich im Script, da in meiner Umgebung der IIS sonst nicht den Content der Challenge-Datei ausgeliefert hat. Ich versuche das nachzustellen und entsprechend anzupassen. Die relevanten Stellen im Script sind die Zeilen welche mit $IISMimeType beginnen (3 an der Zahl). Vieleicht mag mal jemand die Zeilen auskommentieren und testen?
Gruß,
Frank
Hi Frank, freut mich, dass es gelöst werden konnte.
Der Unterschied zum anderen Sbs (b), bei dems funktioniert hat, war, dass ich dein neues Skript nicht verwendet, sondern das bisherige dort versucht hab. Und das hat funktioniert. Daher musste das Problem beim Sbs(a) liegen.
Bei dem Sbs (a), bei dem es mit dem neuen und alten Skript (v1.1+v.3) nicht funktioniert hat, wurde das neue Certificate Assistant (v3) zuerst ausgeführt.
Die nicht erfolgreiche Validierung kam immer wieder, sobald das bisherige Skript (v1.1) oder neue Skript aufgerufen wurde. Installiere aktuell Updates, vielleicht ist es mit einer Framework-Update behoben und es funktioniert.
Dann wäre das "nur" ein Thema von .Net-Framework Version in der Powershell rausfinden und entsprechend vorgehen wegen Mime-Type setzen.
Wird morgen weiter überprüft,
Danke für dein tolles Certificate Assistant Skript und die damit große Unterstützung!
Da ich ähnliche Fehler hatte wie hier schon beschrieben wurden hier meine Beobachtungen:
- Server: 2008 R2 (Enterprise) - jaja, ich weiß - Austausch ist für nächstes Jahr fest eingeplant -.-
- .NET Framework 4.7.2 installiert (in der aktuellsten Version)
- Powershell 5.1
- Manuell angegebene FQDNs (aus diversen Gründen)
Aufgetretene Fehler:
- Wie hier / in den Kommentaren schon geschildert hatte ich den IIS Fehler mit dem doppelten staticContent - habe die 3 Zeilen beginnend mit dem $IISMimeType einfach auskommentiert, danach ging es - das kann allerdings eventuell auch daran liegen, dass vom Ordner .well-known scheinbar auf das Virtuelle Verzeichnis .well-known mit dem Ordner Well-Known gewechselt wurde und wäre damit verbunden mit Fehler 2.
- Fehler, dass Dateien nicht geschrieben wurden. Manuelle Installation von Posh-ACME hat es nicht behoben (allerdings wurde dadurch das Modul nicht bei jedem Start des Scriptes neu installiert - immerhin ein Bonus).
get-paorder | Get-PAAuthorizations
hat einen korrekten / zu erwartenden Inhalt angezeigt, die Order wurden also korrekt angelegt aber nicht ordentlich abgearbeitet.
Analyse hat gezeigt, dass beim Schreibversuch ein sehr komischer "Pfad" generiert wurde... sowas wie
c:\inetpub\wwwroot C:\Program Files (x86)\Trend Micro\Security Server\PCCSRV\WEB \Well-Known \acme-challenge \ xxxxxxxxxxxxxxx
Habe mir dann das zusammensetzen des Pfades angeschaut und der Übeltäter im beim Auslesen des WebsitePaths gefunden
(Get-Website "Default Web Site").PhysicalPath
offensichtlich wird hier ein Array von Pfaden zurück gegeben, wenn mehr als eine Website existiert (und wie aus dem Pfad oben ersichtlich habe ich 2 Websites - das Webinterface installiert sich als 2. Webseite im IIS.
Für meinen persönlichen Fix habe ich einfach den $WebsitePath manuell gesetzt.
Und nein - das 2. Web für den Virenscanner heißt "OfficeScan" und hat nichts mit "Default Web Site" zu tun - '(Get-Website "Default Web Site")' scheint also hier in dieser Kombination etwas anderes zurück zu geben als man erwarten würde.
Ich hoffe das hilft beim allgemeinen Fehlersuchen / jemandem, der eventuell ähnliche Probleme hat.
Und vielleicht noch als Feature Request (wenn man es so nennen möchte): Sollte das Script die Acme-Challenges nicht eventuell löschen, wenn diese abgearbeitet sind? Und ich mein jetzt sowohl die PAOrders / PA-Authorizations als auch die Dateien im Ordner - oder werden die Authorizations fürs erneuern benötigt? (Verwende selbst kein AutoRenew, weil es bei V1 und V2 bei mir nie geklappt hat, bin also nicht soweit im Script durchgegangen.)
Edit: Damit der allgemeine Ton vielleicht nicht ganz so negativ klingt: Respekt und vielen, vielen Dank für das Script, das mir seit Jahren einige Arbeit mit manuellem Installieren der Zertifikate abnimmt und vor allem immer noch für den Exchange 2010 verfügbar ist! Dass der AutoRenew bei mir nie funktioniert hat liegt vermutlich am ehesten daran, dass ich irgendwas falsch eingestellt habe oder so - ehrlicherweise ... hab ich einfach alle 2 Monate einen Termin in Outlook, der mich dran erinnert das Script auszuführen und gut ist - von daher habe ich bisher noch keinen Grund gehabt tatsächlich genau nachzugucken wo oder warum der Fehler im AutoRenew liegt.
Hallo zusammen,
also ich hatte mich nach jahrelangem erfolgreichem Einsatz des v2 Script auf meinem Windows Server 2008R2 mit Exchange 2010 gestern auch einmal um das neue Script bemüht wegen ACMEv2 und habe es auch nicht gleich zum Laufen bekommen. Die Probleme die ich hatte sind ebenfalls:
1. das Posh-ACME musste ich manuell installieren, weil das im Script nicht geklappt hat
2. (Get-Website "Default Web Site").PhysicalPath liefert bei mir zwei Verzeichnisse, weil das Spamverwaltungstool von Sophos eine eigene Website hat und er nicht nur eine bestimmte Website ausgeben kann.
Ich habe das jetzt also händisch installiert und den Pfad fest eingestellt (wie es vorher ja auch mal war) und jetzt scheint es zu Laufen.
Herzlichen Dank für das coole Skript und vielleicht gibts ja bald die neue Version ;)
Servus alle,
erst einmal danke für das Super Script. Habe dieses auf mehreren Systemen schon im Einsatz. Nun ja und aktuell auf einem Server 2008 R2 mit Exchange 2010.
Da bin ich auf dieses hier beschriebene Problem gestoßen.
Damit das Script wieder allgemein gültig wird, müsste nur in Zeile #203 folgendes stehen:
$Websitepath = (Get-Website *"Default Web Site"*).physicalPath
also den Text in zwei **...
anscheinend gibt es hier einen Bug im Powershell was "Spaces im Text" zwischen Anführungszeichen angeht...
Denn wie pheine schon beschrieben hat.. kommt so wie es "programmiert" ist nur eine Sammlung von Pfaden.
Gruß aus dem tiefsten Bayern
SAD*MSG
Hallo,
Die relevanten Stellen im Script sind die Zeilen welche mit $IISMimeType beginnen (3 an der Zahl). Vieleicht mag mal jemand die Zeilen auskommentieren und testen?
ich hatte dasselbe Problem (Server 2012R2 / Exchange 2016) - mit dem Vorschlag hat´s dann funktioniert.
Grüße
$Websitepath = (Get-Website *"Default Web Site"*).physicalPath
Danke! Diese zwei Sternchen haben auch mich gerettet.
Für den Fall dass in Zukunft nochmal jemand anders darauf stößt, bei mir hat obenstehendes leider nicht geholfen. Ich musste mit einer eingeschoeben Zeile
$Websitepath = $Websitepath[0]
nachhelfen