Im Ereignisprotokll taucht Event 36871 auf: Der interne Fehlerstatus is 10013
Wenn im Ereignisprotokoll das Ereignis 36871 auftaucht, ist Windows irrigerweise der Meinung das ein „Schwerwiegender Fehler beim Erstellen der Client-Anmeldeinformationen für TLS. Der interne Fehlerstatus is 10013“ aufgetreten sei.
Je nach Anwendungsfall ist es warscheinlich, das ein Programm auf den Schlüsselspeicher unter
C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys
zugreifen wollte. Das scheint fehlgeschlagen zu sein, vermutlich wegen fehlernde Berechtigungen.
Auf diesen Ordner und alle Dateien darin sollten diese Benutzer Vollzugriff haben:
Netzwerkdienst
SERVICE
SYSTEM
IUSR
Wenn das neu gesetzt wurde, ist der Fehler in aller Regel sofort verschwunden.
Danke an https://www.der-windows-papst.de/2021/02/02/der-interne-fehlerstatus-ist-10013/ 👍
Auf verschiedenen Kundensystemem mit Windows Server 2008R2 (ja, die gibt’s noch) sehen wir in letzter Zeit diesen Fehler. Windows Updates lassen sich nicht mehr installieren und die Traybar sieht etwas seltsam aus:
Die Traybay sieht bei dem Windows Update Fehler 80243004 etwas komisch aus
Die Suche nach neuen Windows Updates funktioniert zwar, aber es tritt bei der Installation immer wieder der Fehler 80243004 auf.
Es gibt gleich zwei Lösungen für das Problem:
Reboot: Nach dem Neustart funktioniert die Installation ohne Fehler
Ohne Reboot: Eigenschaften der Taskleiste -> Infobereich „Anpassen“ -> Windows Update-Symbol von „Nur Benachrichtigungen anzeigen“ umstellen auf „Symbol und Benachrichtigungen anzeigen“
Danach laufen die Windows Updates auf dem System wieder einwandfrei, der Fehler 80243004 ist behoben.
Es ist selten geworden, aber ab und zu taucht noch irgendwo ein „superwichtiger“ alter Windows 7 Client auf. Windows 7 mag nicht immer freiwillig TLS 1.2 sprechen und hat eine WinHTTP Standartkonfiguration, die keine „modern services“ zulässt. Daran scheitern OneDrive, Outlook und andere Microsoft 365 Services und auch private Live-Knto („Microsoft-Konto“) Anmeldungen. Der Fehler 0x8004de40 ist aber immer der selbe und meint „Crypto mit der Cloud schlägt fehl“.
Lösung
Unter Windows 7/8, Server 2008R2/2012/R2 hilft folgendes:
Spätestens jetzt sollte OneDrive wieder fehlerfrei laufen. Wenn das nicht der Fall sein sollte ist es mit an Sicherheit grenzender Warscheinlichkeit eine Drittsoftware (Antivirus, personal Firewall, Security-Software …) oder eine Middlebox (Firewall, SSL-DPI, Security-Kram) vor dem Internet.
Bis vor kurzen wusste ich nicht: Man kann den Anzeigename eines Zertifikats im Zertifikatsspeicher ändern. Die ‚certmgr‘ Konsole lässt das zwar nicht zu, aber an der PowerShell ist das durchaus möglich.
Das XBL Zertifikat aus diesem Beispiel soll umbenannt werden.
1. Den Fingerprint (Thumbprint) des Zertifikates ermitteln:
Windows Server mit dem IIS ist ein ausgezeichneter reverse Proxy und eigentlich auch schnell eingerichtet.
Diese Anleitung geht davon aus das …
Es einen installierten Windows Server 2019 gibt
Ein passendes SSL-Zertifikat mit korrektem CN existiert
Wenn der Webserver im Internet erreichbar ist, tut es natürlich auch Let’s Encrypt
Ein Webserver der über diesen reverse Proxy erreichbar sein soll existiert und auch wirklich von diesem Server erreichbar ist
IIS mit passenden Features installieren
Server Manager > Rollen und Features hinzufügen > „Rollenbasierte oder featurebasierte Installation“ > Server auswählen > „Webserver (IIS)“ und die gewünschten Funktionen hinzufügen. Obligatorisch ist die „IIS-Verwaltungskonsole“
Zertifikat im Windows Zertifikatsspeicher installieren
Doppeklick auf das *.pfx > Lokaler Computer > Weiter > Speicher automatisch auswählen / Kennwort eingeben > Weiter > Fertigstellen
IIS Proxy Dienste einschalten
„Internetinformationsdienste (IIS)-Manager“ (IIS-Konsole) öffnen > Links erster Punkt „Servername“ > Rechte Hälfte „Applicatin Request Routing Cache“ öffnen
In der Taskpane unter „Proxy“ > „Server Proxy Settings“ > Enable Proxy. Ganz unten sollte „Enable SSL Offloading“ eingeschaltet sein.
Tipp: Der X-Forwarded-For Header ist für viele Anwendungen (vor allem Java-Apps) wichtig. Der IIS verbietet im ARR standardmäßig aber alle Header, für die es keine Serverweite Erlaubnis gibt. Wie man eigene Header, zum Beispiel X-Forward-For, im IIS zulässt steht in diesem Artikel: https://www.ugg.li/iis-reverse-proyxy-http-header-setzen-zeigt-nur-fehler-500-seiten/ Wir raten dazu, den Header für Reverse Proxies zu erlauben.
IIS Site anlegen
Es ist zwar zwingend nötig eine neue Site anzulegen, wir raten aber als „best Practice“ dazu, für jede Bindung eine eigene Site mit eigener Konfiguration anzulegen. Die Default Site (ID #1) wird nämlich gerne von Drittsoftware verwendet oder verändert.
Physischer Pfad: <c:\inetpub\www.example.com> (Pfad zur Konfiguration, exklusiv für jede Site anlegen)
Typ: https
IP-Adresse: „Keine zugewiesen“
Hostname: <www.example.com> (URL, muss zum CN im Zertifikat passen)
IIS Site zum Reverse Proxy umstellen
„Internetinformationsdienste (IIS)-Manager“ (IIS-Konsole) öffnen > Servername > Sites > <www.example.com> > „URL Rewrite“ > Regeln hinzufügen > „Reverseproxy“ > Ziel eingeben (hier im Beispiel ein Webserver auf dem localhost auf Port 8080
Optional: HTTPS Redirect Regel erstellen
Um HTTP-Anfragen nun automatisch auf HTTPS weiterzuleiten (via HTTP 30x), kann man nun eine weitere Regel zur Site hinzufügen.
