PowerShell & Scripting

PowerShell-Skriptsignierung (Code Signing)

Allgemeine Infos

Bei der Skriptsignierung versiehst Du PowerShell-Dateien mit einer Authenticode-Signatur. Windows prüft die Signatur bei .ps1, .psm1, .psd1, .ps1xml, .cdxml und .xaml. Unter den Execution Policies AllSigned und RemoteSigned verweigert PowerShell die Ausführung unsignierter Skripte (bei RemoteSigned nur für heruntergeladene Dateien).

Für die Signatur brauchst Du ein Code-Signing-Zertifikat. Es kommt aus einer internen CA (etwa Active Directory Certificate Services) oder gegen Gebühr von einer öffentlichen CA. Selbstsignierte Zertifikate eignen sich nur zum Testen, weil Skripte damit auf anderen Rechnern nicht laufen, solange das Zertifikat dort nicht im Speicher vertrauenswürdiger Stammzertifizierungsstellen liegt.

Die Signaturprüfung gibt es nur unter Windows. Seit PowerShell 7.2 funktionieren signierte Skripte mit jeder Dateikodierung, vorher mussten sie ASCII oder UTF-8 ohne BOM sein.

Funktionsweise & Details

Ablauf beim Signieren:

  1. Code-Signing-Zertifikat beschaffen und im Zertifikatspeicher ablegen, für Tests z. B. mit New-SelfSignedCertificate -Type CodeSigning.
  2. Zertifikat laden, etwa mit Get-ChildItem Cert:\CurrentUser\My -CodeSigningCert.
  3. Set-AuthenticodeSignature signiert die Datei und hängt einen Kommentarblock an, der mit # SIG # beginnt und endet. Standard-Hashalgorithmus ist seit PowerShell 7.3 SHA256, vorher SHA1. -IncludeChain steuert, welche Zertifikate der Kette eingebettet werden (Standard NotRoot).
  4. Mit -TimestampServer setzt Du einen Zeitstempel. Dadurch bleibt die Signatur gültig, auch wenn das Zertifikat später abläuft. Die URL muss mit http:// beginnen, weil die zugrunde liegende API kein HTTPS unterstützt.
  5. Get-AuthenticodeSignature prüft den Status einer Signatur.

Jede Änderung am Skript macht die Signatur ungültig, Du musst danach neu signieren.

Vorteile & Nutzen

  • Integrität: Manipulierte Skripte fallen auf, weil die Signatur nach jeder Änderung nicht mehr passt
  • Herkunftsnachweis: Die Signatur zeigt, welches Team oder welcher Dienstleister ein Skript freigegeben hat
  • Voraussetzung für AllSigned: Mit signierten Skripten kannst Du die strengste Execution Policy durchsetzen
  • Langlebigkeit durch Zeitstempel: Skripte laufen auch nach Ablauf des meist einjährigen Zertifikats weiter

Praxisbeispiel

Ein Automobilzulieferer mit 800 Mitarbeitenden muss im Rahmen seiner TISAX-Anforderungen nachweisen, dass nur freigegebene Skripte auf Servern laufen. Die IT stellt über die interne AD-CS-Zertifizierungsstelle ein Code-Signing-Zertifikat für das Automatisierungsteam aus und setzt per Gruppenrichtlinie AllSigned auf den Produktivservern. Freigegebene Skripte signiert eine Build-Pipeline mit Zeitstempel, das Zertifikat liegt nicht auf Admin-Arbeitsplätzen. Unsignierte Testskripte laufen nur noch in der Testumgebung.

Worauf sollte man achten?

  • Den privaten Schlüssel des Signaturzertifikats schützen, idealerweise in einem HSM oder Key Vault, weil jeder Besitzer beliebige Skripte als vertrauenswürdig signieren kann
  • Immer mit Zeitstempelserver signieren, sonst laufen Skripte nach Ablauf des Zertifikats nicht mehr
  • Signierung in einen Freigabeprozess oder eine Pipeline einbinden, statt sie manuell auf Admin-PCs zu erledigen
  • Die Signatur ersetzt keine Codeprüfung: Sie belegt nur, wer signiert hat, nicht dass der Code sicher ist

Lizenz & Verfügbarkeit

Set-AuthenticodeSignature ist in PowerShell unter Windows enthalten. Zertifikate aus einer internen CA (AD CS, Bestandteil von Windows Server) verursachen keine Zusatzlizenz, Code-Signing-Zertifikate öffentlicher CAs sind kostenpflichtig. Stand: Oktober 2026.

Fazit

Skriptsignierung ist die Grundlage, wenn Du per AllSigned nur freigegebene Skripte zulassen willst. Entscheidend sind ein gut geschützter Signaturschlüssel und Zeitstempel.

Weiterführende Links

Verwandte Artikel