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:
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:
Als Trigger könnten zum Beispiel alle 2 Monate ausgewählt werden, so bleibt genug Zeit zum manuellen Eingreifen falls etwas schief geht:
Als Aktion wie gehabt den Pfad zur PowerShell angeben und als Argument den Pfad zum Script:
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.
Hallo Frank!
Das Problem, das Dennis am 9.11. beschreibt, kann ich (leider) vollumfänglich bestätigen und teile seine Nervosität!
Die Erstellung eines neuen Accounts ist aktuell nicht möglich, die Erzeugung eines Zertifikats entsprechend auch nicht!
Großes Problem!
Gibt es da evtl. schon einen Ansatz deinerseits?
Grüße,
Karl
Hallo Frank,
der Certificate Assistant scheint tatsächlich kurzfristig in echte Probleme zu laufen! Tobias hatte schon im Oktober Probleme neue Zertifikate zu generieren, kurz darauf ging es aber wieder. Der Link in der Fehlermeldung verweist auf einen offiziellen Eintrag im Let´s Enrcypt Forum, in dem das Ende von ACMEv1 offiziell angekündigt wird.
https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430
In November of 2019 we will stop allowing new account registrations through our ACMEv1 API endpoint. Existing accounts will continue to function normally.
In June of 2020 we will stop allowing new domains to validate via ACMEv1.
Auch ich kann derzeit keine neuen Registrierungen mehr machen. Da wir Dein wirklich großartiges Projekt mittlerweile in zahlreichen Installationen verwenden, werde ich jetzt natürlich etwas nervös.Kannst Du Deine Community kurz darüber aufklären, ob es eine neue Version geben wird oder ob wir uns neu orientieren müssen?
Vielen lieben Dank und wenn ich als Tester helfen kann, melde Dich.
Gruß
Dennis
Perfekt
Das war´s
Danke
Hi Markus,
klar, sorry, hatte vorhin keinen PC zu Hand und die Datei nicht vor Augen. Die Einstellungen sind in der Powershell Datei für Deine Exchange-Version zu finden (CertificateAssistent_v2_EX20??.ps1
Darin ist eine Zeile $DetermineExchangeFQDNs = $true enthalten. Das setzt Du auf $false. Im Abschnitt danach definierst Du unter $CustomFQDNs = @(„servername.domain.tld“,“server2.domain.tld“) alle Deine URLs, die im Zertifikat enthalten sein sollen. Achte auf die Anführungszeichen und die Kommatrennung zwischen den Hostnamen.
Viel Erfolg weiterhin.
Dennis
Du kannst im Config File die automatische Erkennung der Hostnamen deaktivieren und stattdessen angeben, welche Namen im Zertifikat enthalten sein sollen. Denk aber daran, dass im DNS der Domain02 die Namen auch auf die selbst IP zeigen. Nur der MX reicht nicht.
Viel Erfolg!
Hallo Dennis,
kannst Du mir verraten wo ich das im Config File finde?
Die DNS Einträge habe ich soweit richtig gesetzt.
Hallo Franky,
erstmal Danke für deine Seite und die wirklich tollen Tipps.
Ich habe das auf meinem SBS2011 eingerichtet und es funktioniert soweit ohne Probleme.
Im Zertifikat stehen folgende Antragstellernamen:
DNS-Name=autodiscover.domain01.at
DNS-Name=email.int.domain01.at
DNS-Name=email.domain01.at
Jetzt habe ich aber auf meinem Exchange eine zweite Domain „domain02.com“ unter „Akzeptierte Domänen“ angelegt.
Im DNS habe ich eine neue Zone domain02.com eingerichtet und den Eintrag autodiscover angelegt.
Der MX Eintrag für die neue Domain ist „email.domain01.at“.
Das Einrichten und der Zugriff mit Outlook (2019) von außen funktioniert soweit ohne Probleme.
Leider bekomme ich aber immer die Sicherheitsmeldung dass der Name auf dem Sicherheitszertifikat ungültig ist.
Gibt es eine Möglichkeit in das Zertifikat den Namen
DNS-Name=autodiscover.domain02.com
zu integrieren?
Hallo Franky,
vielen Dank für das tolle Skript.
Ich möchte es gerade bei einem Exchange 2010 einrichten, es kann aber keine LE Registration durchgeführt werden.
Folgender Fehler wird ins Log geschrieben:
18.10.2019 10:26:53;Check Registration;Info;Lets check if exists a LE registration;
18.10.2019 10:26:53;Check Registration;Warning;No Registration found, try to create one;No registrations found
18.10.2019 10:26:54;Check Registration;Error;Can’t create registration, exiting script;Unexpected error
+Response from server: + Code: Forbidden + Content: { „type“: „urn:acme:error:unauthorized“, „detail“: „Account creation on ACMEv1 is disabled. Please upgrade your ACME client to a version that supports ACMEv2 / RFC 8555. See https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430 for details.“, „status“: 403}
Es können also keine neuen Accounts mehr mit ACMEv1 mehr erstellt werden.
Was kann ich tun?
Hallo zusammen,
ich wollte nur Bescheidgeben, dass es ein paar Tage später auf einmal funktioniert hat.
Seitdem keine Probleme mehr.
Hallo, ja der Server war erreichbar. Aber das Problem konnte ich (mit Hilfe eines anderen Kommentares hier auf Frankys Web) lösen. Tolle Community hier muss ich sagen! Auch das Lösungen immer wieder nachträglich in die Kommentare gepostet werden finde ich großartig!
Die Lösung (bei mir): mit dem Eintrag der Subdomain wurde automatisch ein AAAA-Eintrag mit IPV6-Adresse von 1&1 angelegt. Let’sEncrypt priorisiert diesen wohl. Nachdem ich den Eintrag bei 1&1 rausgeschmissen habe, rannte das Script sauber durch!
Hier der Kommentar, der mir die Lösung zeigte:
https://www.frankysweb.de/exchange-certificate-assistant-neue-version/#comment-59917
Bei mir kam dieser Fehler weil in der Firewall der Port 80 nicht zum Exchange geforwardet wurde.
Ist der Server ganz sicher per http erreichbar?
Hallo! Wir erhalten auch den Fehler:
+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.meinedomain.de“,
„status“: 403
}
Konnte das bisher irgendjemand lösen?
Windows Server 2012R2 und Exchange 2013 CU 22
Hallo Franky,
ich möchte mich vielmals für diesen und viele weitere Artikel bedanken, ohne dessen Hilfe ich mit Sophos und Exchange 2016 vermutlich nicht klar gekommen wäre. Sophos war für mich bisher immer ein rotes Tuch, was aber eher der „Angst“ für vor Firewalls geschuldet war. Nachdem ich dank deiner Anleitung Sophos ein wenig kennengelernt habe muss ich sagen, dass Sophos wirklich ein unglaubliches Produkt ist (und das auch noch kostenlos).
Ein paar Stolpersteine gab es aber dennoch, namentlich genannt „LetsEncrypt Zertifikate“. Ich habe es einfach nicht hinbekommen mit deinem Zertifikats-Skript und IIS. Offenbar hat Sophos das verhindert. Die Zertifikatsanforderung wurde ständig beim Senden an LetsEncrypt abgerochen. Außerdem musste ich mit einer anderen Anleitung im Quellcode der Sophos rumpfuschen, damit der DNS-Provider Allinkl.com funktioniert.
Letztendlich habe ich all diese Probleme sehr einfach gelöst. Für meine Subdomain fordert nun Sophos das SAN-Zertifikat an, welches ich nach wie vor manuell auf dem Exchange 2016 installieren muss. Das ist zwar keine schöne Lösung, aber eine Lösung. Das erscheint mir aktuell besser, als X-Tage nach Lösungen zu suchen, die möglicherweise auch ein Bug im IIS oder in Server 2016 sein können.
Also, nochmal danke für deinen wirklich außergewöhnlichen Blog! Und natürlich auch an alle anderen hilfreichen Kommentaren.
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!!
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
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
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
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
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
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
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?
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
}
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;
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!
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 :)
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!
Port 80 meinte ich natürlich
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.
Also ich habe das hier auf einem 2012 anwenden können und hat sofort geklappt:
https://support.microsoft.com/en-us/help/937536/error-message-when-client-computers-encrypt-a-file-in-a-windows-server
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?
ich sehe gerade, in dem Script musst du eine gültige E-Mailadresse hinterlegen.
Das scheint auch nicht erledigt worden zu sein.
@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
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.
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
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
Hallo Frank,
wollte mal nachfragen ob es bereits eine Lösung zu meinem Fehler gibt?
Gruß,
Hölli
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
Hallo Dennis,
für die nächste Version plane ich auch die DNS Validierung mit einzubauen, bzw. als Alternative zur HTTP Validierung.
Gruß,
Frank
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
Ich hatte heute nach einer Zertifikatserneuerung(die ohne Fehler durchläuft) folgendes Problem:
https://www.administrator.de/wissen/exchange-2013-backend-nicht-verf%C3%BCgbar-event-id-15021-httpevent-243553.html
Ich musste den Port 444 manuell wieder zuweisen, danach funktionierte wieder alles …
Seltsam, ich habe das Script schon mehrere Male verwendet und dieses Problem hatte ich noch nie…
Hallo Frank
Danke für deine Rückmeldung. Log ist per Mail raus.
LG
Oliver
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
Hi Oliver,
ich habe eine Vermutung wo es hakt, kannst du mir bitte das komplette Log per Mail schicken?
Gruß,
Frank
Hallo Frank,
danke für den Hinweis, das ist mir irgendwie durch die Lappen gegangen.
Gruß,
Jan
Hallo Frank,
hab ich dir geschickt.
Gruß,
Hölli
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
Hallo Hölli,
schick mir bitte das komplette Log per Mail, dann schau ich mal nach.
Gruß,
Frank
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 …
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
Hallo Jan,
das Problem liegt un ungültigen EFS-Zertifikaten, Tielmann hat hier in den Kommenaren bereits den passenden Link veröffentlicht:
https://support.microsoft.com/en-us/help/937536/error-message-when-client-computers-encrypt-a-file-in-a-windows-server
Gruß,
Frank
Das Warnmeldungsproblem ist auch gelöst, Das Problem lag vor dem Monitor. :-) hatte noch eine altenUrl aufgerufen, die nicht mehr in der Zertifikatskonfig ist.
Hallo Andi,
schön das es nun funktioniert, hätte erwartet das der SBS mehr Zicken macht :-)
Gruß,
Frank
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
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?
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
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.
Wird auch noch Win Srv 2012 unterstützt werden?
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
Vielen Dank das werde ich mal an einem 2013er testen