Der eine oder andere Administrator ist sehr wahrscheinlich auch über das folgende Problem gestolpert, als er bei dem Versuch die Windows Updates für Microsoft .NET 4.0 einzuspielen

  • Sicherheitsupdate für Microsoft .NET Framework 4 (KB2656351)
  • Sicherheitsupdate für Microsoft .NET Framework 4 (KB2656368)
  • Update für Microsoft .NET Framework (KB2600217)

diese Fehlermeldung im Systemereignisprotokoll (Quelle: Windows Update Agent, Event-ID 20) erhielt:

Installationsfehler: Die Installation des folgenden Updates ist mit Fehler 0×80070643 fehlgeschlagen: Sicherheitsupdate für Microsoft .NET Framework 4 unter Windows XP, Windows Server 2003, Windows Vista, Windows 7, Windows Server 2008 x86 (KB2656351)

Problem

In meinem Fall trat der obige Fehler auf einigen (kurioserweise nicht auf allen!) Maschinen unter Windows Server 2003 (32 Bit) inkl. Service Pack 2, aber auch unter Windows Server 2008 (64 Bit Version) inkl. Service Pack 2 auf. Bei letzterem Betriebssystem lieferte Windows Update einen weiteren Fehlercode 800b010b, welcher mich letztendlich bei meiner Fehleranalyse auf die richtige Fährte führte:

Bei meiner Suche nach dem ersten Fehlercode 80070643 stieß ich auf den folgenden Microsoft Support KB Eintrag. Wie beschrieben lud ich das .NET Framework Cleanup Tool für die Reparatur der .NET Framework Umgebung herunter und führte selbiges mit der Option Cleanup Now aus:

Das Tool entfernt dabei alle .NET Framework Einstellungen (per Auswahl auch auf einzelne Versionen beschränkbar) von dem betroffenen System. In Folge dessen musste ich nun alle .NET Framework Versionen (unter Windows Server 2003 sind das immerhin Version 1.1, 2.0, 3.0, 3.5 und 4.0 inkl. aller Service Packs) neu installieren. Dank internem Windows Update Server (WSUS) kein Problem – doch nach der Installation der oben aufgeführten Updates und mehreren Neustarts erhielt ich die selben Fehlermeldungen erneut – eine Bereinigung und anschließende Neuinstallation behebt das Problem demnach nicht.

Analyse und Ursache

Jedes Windows Update legt bei der Installation ein Protokoll im temporären Verzeichnis des Systems an (%TEMP%\KB<Nummer>.html). In diesem Protokoll wird für die betroffenen Updates immer die gleiche Ursache genannt (hier das Beispiel für KB2656368):

Action: Downloading and/or Verifying Items...
[4/24/2012, 8:54:49] Verifying Digital Signatures: d:\f4fc31bd6ed42ecc7c4387d680\NDP40-KB2656368.msp
[4/24/2012, 8:54:49] d:\f4fc31bd6ed42ecc7c4387d680\NDP40-KB2656368.msp: Verifying signature for NDP40-KB2656368.msp...
[4/24/2012, 8:54:49] d:\f4fc31bd6ed42ecc7c4387d680\NDP40-KB2656368.msp - Signature verification for file NDP40-KB2656368.msp (d:\f4fc31bd6ed42ecc7c4387d680\NDP40-KB2656368.msp) failed with error 0x800b010e (Der Sperrvorgang konnte nicht fortgesetzt werden. Die Zertifikate konnten nicht überprüft werden.)
[4/24/2012, 8:54:49] d:\f4fc31bd6ed42ecc7c4387d680\NDP40-KB2656368.msp Signature could not be verified for NDP40-KB2656368.msp
[4/24/2012, 8:54:49] No FileHash provided. Cannot perform FileHash verification for NDP40-KB2656368.msp
[4/24/2012, 8:54:49] File NDP40-KB2656368.msp (d:\f4fc31bd6ed42ecc7c4387d680\NDP40-KB2656368.msp), failed authentication. (Error = -2146762482). It is recommended that you delete this file and retry setup again.
[4/24/2012, 8:54:49] Failed to verify and authenticate the file -d:\f4fc31bd6ed42ecc7c4387d680\NDP40-KB2656368.msp
[4/24/2012, 8:54:49] Please delete the file, d:\f4fc31bd6ed42ecc7c4387d680\NDP40-KB2656368.msp and run the package again
[4/24/2012, 8:54:49] Action complete
[4/24/2012, 8:54:49] calling PerformAction on an installing performer
[4/24/2012, 8:54:49] Action: Performing actions on all Items...
[4/24/2012, 8:54:49] Wait for Item (NDP40-KB2656368.msp) to be available
[4/24/2012, 8:54:50] Action complete
[4/24/2012, 8:54:50] Sending Manifest Report
[4/24/2012, 8:54:51] Final Result: Installation failed with error code: (0x800B010B), "Allgemeiner Vertrauensfehler." (Elapsed time: 0 00:00:03).

Es ist erkennbar, dass das im Update enthaltene Paket (NDP40-KB2656368.msp) eine digitale Signatur enthält, deren Überprüfung fehlschlägt. Über die Eigenschaften der MSP-Datei lässt sich diese Signatur anzeigen:

Bei dem Klick auf Details erhielt ich daraufhin den folgenden Fehler:

Lässt man sich nun das Zertifikat des Signaturgebers (Microsoft) anzeigen, so kann Windows die Gültigkeit des Zertifikats nicht bestätigen, da das Programm keine gültige Zertifikatsperrliste von der Zertifizierungsstelle ermitteln kann, die dieses Zertifikat ausgestellt hat.

Die Zertifikatsperrliste (Certificate Revocation List = *.crl) ist eine Datei, über die ein Aussteller abgelaufene und kompromittierte Zertifikate für ungültig erklären kann. Die URL für die CRL ist dabei immer in den Eigenschaften eines Zertifikates verankert. Kann die Sperrliste einmal nicht geladen werden, so geht ein Client im Standard immer von der Ungültigkeit eines Zertifikates aus.

Für die beschriebene Datei gibt es nun 3 in Frage kommende (weil hinterlegte) Sperrlisten:

Normalerweise lässt sich die Erreichbarkeit/Verfügbarkeit der jeweiligen CRL durch das Herunterladen prüfen – alle CRLs waren aber erreichbar und konnten erfolgreich heruntergeladen werden. Trotzdem konnte das Zertifikat nicht überprüft werden.

Lösung

Bei der Fortsetzung meiner Suche fand ich schließlich den folgenden, wertvollen Hinweis im Technet-Forum von Microsoft. Eigentliche Ursache für das beschriebene Verhalten sind die System-Einstellungen für die Zertifikat-Überprüfung (Software Publishing State Key Values).

Mit Hilfe des Tools SetReg.exe von Microsoft – welches im Microsoft .NET Framework SDK enthalten ist – lassen sich diese aktuellen Einstellung anzeigen und ändern. Auf den Systemen, auf denen die Updates nicht installiert wurden, zeigte SetReg folgende Werte:

Software Publishing State Key Values (0xc9):
 1) Trust the Test Root........................... TRUE
 2) Use expiration date on certificates........... TRUE
 3) Check the revocation list..................... TRUE
 4) Offline revocation server OK (Individual)..... FALSE
 5) Offline revocation server OK (Commercial)..... FALSE
 6) Java offline revocation server OK (Individual) FALSE
 7) Java offline revocation server OK (Commercial) FALSE
 8) Invalidate version 1 signed objects........... FALSE
 9) Check the revocation list on Time Stamp Signer TRUE
 10) Only trust items found in the Trust DB....... FALSE

Im erwähnten Technet-Eintrag wurde der Punkt 5 Offline revocation server OK (Commercial) als kritisches Element beschrieben. Setzt man diesen über den Befehl

setreg 5 TRUE

auf wahr (allows offline approval for commercial certificates), so lassen sich die Windows Updates ohne Probleme installieren. Außerdem funktioniert danach die Anzeige des Zertifikates des Signaturgebers der MSP-Paketdatei ebenfalls ohne Probleme:

Das Herunterladen des ca. 115 MByte (!) großen .NET Framework SDK für die Ausführung von SetReg kann man sich allerdings sparen, da selbiges Tool lediglich einen Wert in der Registry verändert. In meinem Fall hatte der betroffene Benutzer auf dem System den folgenden Eintrag:

[HKCU\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing]
“State”=DWORD:000000c9

Setzt man nun diesen Wert auf

“State”=dword:00022849

so entspricht diese Einstellung den auf der Webseite für SetReg beschriebenen DEFAULT Werten:

Updated Software Publishing State Key Values (0x22849):
 1) Trust the Test Root........................... FALSE
 2) Use expiration date on certificates........... TRUE
 3) Check the revocation list..................... TRUE
 4) Offline revocation server OK (Individual)..... FALSE
 5) Offline revocation server OK (Commercial)..... TRUE
 6) Java offline revocation server OK (Individual) FALSE
 7) Java offline revocation server OK (Commercial) TRUE
 8) Invalidate version 1 signed objects........... FALSE
 9) Check the revocation list on Time Stamp Signer FALSE
 10) Only trust items found in the Trust DB....... FALSE

Nach dieser simplen und kleinen Änderung funktioniert die Installation der Windows Updates KB2656351, KB2656368 und KB2600217 ohne Probleme.

Fazit

Obwohl ich bereits das eine oder andere Problem mit Windows Updates für das Microsoft .NET Framework lösen musste, verlangte der hier beschriebene Fehler einen extremen Zeit- und Arbeitsaufwand (erkennbar am Umfang des Artikels). So habe ich allein für die Suche und Analyse mehrere Stunden investieren müssen. Warum und vor allen Dingen welches Programm den Standardwert für die Software Publishing Key Values von 23c00 (siehe .DEFAULT Benutzerprofil) auf c9 abgeändert hat, bleibt mir ein Rätsel. Umso überraschender ist doch die recht schnelle und einfache Behebung des Problems, mit dessen Lösung ich hoffentlich anderen Leidensgenossen helfen kann.

Wie bei allen meinen Beiträgen gilt: Bei Tipps, Vorschlägen sowie Fragen oder Kritiken hinterlasst bitte einen Kommentar.