279: Bald kein Vertrauen mehr zu Schlüsseln unter 1024 Bit Länge

Wir verwenden den System Center Updates Publisher (SCUP) zur laufenden Aktualisierung von Adobe Reader und Flash Player. Im Prinzip funktioniert das Tool folgendermaßen:

  • der Herstellerkatalog wird mit SCUP in den WSUS integriert und Clients können dagegen scannen und z.B. feststellen, dass Flash aktualisiert werden muss.
  • der Admin verwendet die SCUP Konsole um das Update im WSUS bzw. im SCCM bereitzustellen.
  • dabei wird das Update vom Hersteller heruntergeladen und mit einem eigenen Signaturzertifikat signiert. Das Zertifikat kann durch den SCUP selbst signiert sein oder man verwendet ein Codesignatur Zertifikat einer eigenen CA.
  • am Client muss das Zertifikat (der öffentliche Schlüssel) in den „Trusted Root“ und in den „Trusted Publisher“ Bereich des Zertifikatsspeichers importiert werden.
  • während des Update Deployments prüft Windows ob es dem Zertifikat „traut“ bevor das Update installiert wird.

Soweit alles ok und funktioniert(e) auch prima. Nachdem nun einige Windows 8 Maschinen in der Domäne auftauchten fiel auf, dass durchweg die per SCUP bereitgestellten Updates fehlschlagen. Im Normalfall sind 90% der Probleme beim SCUP auf Zertifikate zurückzuführen. Eine Überprüfung ergab, dass alle Bedingungen auf Windows 8 Maschinen identisch zu Windows 7 oder XP Maschinen waren. Warum funktionierts dann aber nicht?

Das Zertifikat wird auf einer Windows 8 Maschine so dargestellt:

Das Zertifikat wurde damals der Einfachheit halber vom SCUP selbst signiert. Merkwürdig: Es ist nicht abgelaufen, der öffentliche Schlüssel der CA befindet sich im „Trusted Root“ Speicher. Trotzdem vertraut Windows 8 dem Zertifikat nicht.

Beim Recherchieren bin ich auf diese beiden Blogeinträge gestoßen:

http://blogs.technet.com/b/pki/archive/2012/06/12/rsa-keys-under-1024-bits-are-blocked.aspx

http://blogs.technet.com/b/pki/archive/2012/07/13/blocking-rsa-keys-less-than-1024-bits-part-2.aspx

Offensichtlich soll jetzt im August ein Update veröffentlicht werden das dazu führt, dass Schlüssel mit einer Schlüssellänge unter 1024 Bit nicht mehr vertrauenswürdig sind. Dieses „Feature“ ist wohl bei Windows 8 schon eingebaut. Und tatsächlich enthält das vom SCUP ausgestellte Zertifikat einen nur 512 Bit langen öffentlichen Schlüssel.

Ich habe dann in meinem Fall ein Zertifikat vom Type „Code signing“ mit 1024 Bit Schlüssellänge von der eigenen CA angefordert. Kleiner Nachteil war dabei, dass alle Updates nochmal neu signiert werden und der Schlüssel noch in die „Trusted Publisher“ der Clients verteilt werden musste.

Was mit SCCM Software Deployment kein Act ist:

certutil.exe -addstore TrustedPublisher "%~dp0scup-codesigning.cer"

Im Blog sind andere Workarounds beschrieben mit denen die Anforderung auf min. 1024 Bit wieder heruntergeschraubt werden kann. Die funktionieren auch, aber an sich ist das „Anziehen der Schraube“ schon eine gute Sache. Bin gespannt wo noch überall kurze Schlüssel auftauchen.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

%d Bloggern gefällt das: