wie einige von euch schon wissen, gibt es im APC die Möglichkeit, PowerShell-Skripte zu signieren.
Wir möchten erneut betonen, wie wichtig es ist, diese Funktion zu nutzen. Deshalb möchte ich hier kurz erläutern, warum:
Damit unsere Pakete auch Benutzerdaten installieren können oder eine alte Version bei einer Update-Installation sauber deinstalliert werden kann, werden die PowerShell-Pakete immer lokal auf dem Rechner gespeichert. In der Regel befinden sich diese unter folgendem Pfad: C:\ProgramData\neo42Pkgs\<Hersteller>\<Softwarename>\<Version>\neo42-Install.
Falls in Zukunft entschieden wird, dass nur noch signierte PowerShell-Skripte im Unternehmen ausgeführt werden dürfen, liegen auf allen Clients unsignierte Skripte – was nachträglich nicht mehr geändert werden kann.
Mögliche Gründe für die Einführung dieser Richtlinie gibt es viele… Vielleicht sieht es eine neue ISO Zertifizierung vor oder die Cyberversicherung verlangt diesen Schritt. Natürlich trägt diese Einstellung auch zur IT-Sicherheit bei und sollte allein deshalb schon beleuchtet werden.
Daher ist es äußerst wichtig, dem vorzubeugen und das Skript-Signing in den Pipelines zu aktivieren.
Um die Einrichtung zu erleichtern, haben wir zwei Dokumente erstellt. Eines beschreibt die Empfehlungen zur Powershell-Scriptsignierung, das Andere ist eine Anleitung zur praktischen Umsetzung.
Beim Erstellen des Script Signings im Application Package Center bekomme ich diesen Error, nachdem ich das Zertifikat, Password und Timestamp Server URL angegeben habe:
Zertifikat und Password sind korrekt, als Zeitserver habe ich den vorgegebenen und auch diverse andere ausprobiert. NTP Zugriff sollte eigentlich generell klappen.
Irgend eine Idee oder gibt es ein Log indem ich mehr Details zum Problem finde?
Hi, jetzt habe ich mal kurz eine Frage als Certifikatsneuling
Ich habe anhand der Zertifikatsvorlage nun ein Zertifikat auf dem MMS Server erstellt.
Habe dann
den privaten Schlüssel exportiert, dieser wird in die Pipelines eingebunden
den öffentlichen Schlüssel exportiert, dieser wird über GPO verteilt
Jetzt meine Frage. Mein Zertifikat das ich erstellt habe, hat ja eine Dauer von X.
Was passiert nun wenn das Zertifikat abläuft? Sind dann meine vorhandenen signierten Scripte verfallen…
Ich erneure mein Zertifikat am MMS Server gegen die CA.
Anschließend exportiere ich wieder privaten und öffentlichen Schlüssel? Diese werden dann in den MMS und in der GPO verteilt.
Aber was ist dann mit den Paketen die ich davor erstellt und signiert habe?
Sorry den Zusammenhang hab ich noch net erfasst, weil an den Paketen ändert sich ja der Hash nicht durch den Vorgang?!
sehr gute Frage, die sich schnell beantworten lässt.
Das Zertifikat muss zum Zeitpunkt der Signierung gültig sein. Aus diesem Grund wird der Zeitserver angegeben. Dieser verifiziert, dass das Zertifikat zum Zeitpunkt der Signierung gültig war. Sollte das Zertifikat in Zukunft ablaufen, bleiben also die signierten Scripte dennoch gültig.
Natürlich ist es ratsam sich einen Reminder zu stellen, damit das CodeSigning Zertifikat im MMS rechtzeitig erneuert wird.
Aber ich als Noob in Sachen Zertifikat hab doch noch ein paar Fragen.
Ich muss also mein Zertifkat im MMS erneuern, und den neuen Privaten key wieder im MMS Script einpflegen, damit neue Scripte signiert werden.
Muss ich auch den öffentlichen Schlüssel wieder exportieren und wieder über GPO verteilen? Damit die signierten Scripts mit dem alten und neuen privaten Keys signierten, Safe sind?
Was passiert wenn ich jetzt z.B. ein Script signiert habe und ein neues Zertifikat verwende also kein erneuern sondern ein neues ausstelle weil sich z.B die Vorlage geändert hat, oder der erneuerungszeitraum überschritten wurde?!
Sorry ich versteh hier nur Bahnhof. Ich kanns zwar technisch umsetzen, sehe aber die Zusammenhänge in der Zukunft noch net wirjklich
Hi Danke für die Antwort also fasse ich kurz zusammen:
Neu
Erstelle eine Zertifikatsvorlage
Vordere ein Zertifikat mit dem APD User anhand der Vorlage an
Exportiere den Privaten Schlüssel und für dem der Pipeline hinzu
Öffentlicher Schlüssel wird über AD GPO oder andere Mechanismen verteilt
Ablauf
Zertifikat verlängern über „dieses Zertifikat mit demselben Schlüssel erneuern“
Exportieren den Privaten Schlüssel für die Pipeline
öffentlicher Schlüssel wieder über GPO oder andere Mechanismen verteilen
Die alten Pakete sind weiterhin signiert mit dem alten privaten Schlüssel der über den Timestamp bei der Signierung unbegrenzt gültig ist oder nur in Verbindung mit dem neuen öffentlichen Schlüssel?
Das hab ich noch net ganz verstanden. Wenn doch ein Paket vor der Verlängerung signiert wurde ist dies ja anhand des Timestamp gültig auch wenn das Zertifikat ( öffentlicher Teil ) abläuft. Warum erneuere ich den öffentlichen Teil dann überhaupt und mache das nicht nur mit dem Privaten Schlüssel in den Pipelines?!
Wenn das Zertifikat auf diesem Weg „verlängert“ wird, dann bleibt nur der private Teil gleich. Der öffentliche Teil ändert sich und muss neu verteilt werden.
Die alten Pakete behalten ihre gültige Signatur durch den Zeitstempel auch nach Ablauf des Zertifikats. Die Notwendigkeit das alte Zertifikat weiterhin zu verteilen hängt daran, dass PowerShell es benötigt, um dem Publisher zu vertrauen. Das neue Zertifikat muss verteilt werden, damit den Paketen die damit signiert werden auch vertraut wird.
hä? Ich veteile also immer den neuen öffentlichen Schlüssel nach der verlängerung, muss aber für die alten signirungen den alten öffentlichen zugänglich lassen? Dann baue ich mir ja eine ewige Liste mit abgelaufenen öffentliochen Schlüsseln auf?!
Da wir ja auch Geräte ausserhalb der Domain haben, sind wir am Überlegen ob wir hier ein öffentlich ausgestelltes Zertifikat erwerben, dass eine generelle Gültigkeit besitz unabhängig unserer Domain.
Ja richtig verstanden. Bei einer üblichen Gültigkeit von 2-3 Jahren ist das aber auch nach 10 Jahren noch eine überschaubare Liste.
Auch externe bzw. „gekaufte“ Code Signing Zertifikate muss man allerdings in den Trusted Publisher Store ablegen. Das die Zertifikate allgemein bekannt sind ändert nichts daran, dass der jeweilige Rechner ihm für die Ausführung von Skripten vertraut oder nicht.
