Für bestimmte Zwecke muss man eine eigene Vor­lage für das An­fordern von Zerti­fikaten erstellen, zum Beispiel für das Sig­nieren oder Ver­schlüsseln von Scripts. Wenn man dann ein Zerti­fikat von einer Windows-CA auf Basis eines solchen Temp­lates anfordert, dann ist dieses aber meistens nicht ver­fügbar.

Power­Shell 5.x unterstützt den IETF-Standard Crypto­graphic Message Syntax (CMS) zur Ver­schlüs­selung von Da­teien oder Log-Einträgen. Dafür be­nötigt es ein Zerti­fikat, das speziell für diesen Zweck ausge­stellt wurde. Möchte man es von einer Windows-CA anfordern, dann muss man dafür erst ein Temp­late ein­richten.

Mozilla stattet Fire­fox mit einer Daten­bank für Zertifikate aus, die ab Werk eine Reihe von Stamm­zertifikaten ent­hält. Ver­teilt man etwa selbst­signierte Zerti­fikate mittels GPO an Clients, dann bleiben sie deshalb für Firefox unbe­kannt. Über eine Ein­stellung kann Firefox aber Zertifi­kate aus dem Windows-Speicher impor­tieren.

Nutzt man auf dem Server zur Ab­sicherung von Ver­bindungen ein Zerti­fikat, dessen Heraus­geber die Clients nicht trauen, dann werden die Be­nutzer mit einer War­nung kon­frontiert. Um dies zu ver­meiden, kann man das Zertifikat in den Store der PCs über­tragen, bevor­zugt über GPO oder auch via PowerShell.

Neben den gängigen GUI- und CLI-Tools ist unter den Bord­mitteln von Windows auch Power­Shell in der Lage, die Aus­stellung eines Zertifikats anzu­fordern. Das dafür zuständige Cmdlet weist zwar einige Ein­schränkungen auf, eignet sich aber zum Beispiel dazu, ein SSL-Zertifikat von einer internen CA aus­stellen zu lassen.

Installiert man das Windows Admin Center (WAC) auf einem Server, dann sollte der Browser mit dem Gateway über eine sichere Ver­bindung kommunizieren. Das WAC bringt dafür zwar ein Zerti­fikat mit, aber dieses ver­ursacht eine Sicher­heits­warnung des Browsers. Daher sollte man es durch ein eigenes Zerti­fikat ersetzen.

Verbindungen, die man über Enter-PSSession und Invoke-Command aufbaut, kommu­nizieren stan­dard­mäßig über HTTP. Aller­dings ver­schlüsselt dabei WinRM die über­tragenen Daten. Zusätz­liche Sicher­heit erlangt man speziell in Work­groups durch HTTPS, wobei ein selbst­sig­nierten SSL-Zertifikat in der Regel reicht.

Während man früher Tools wie makecert.exe benö­tigte, um selbst­signierte Zerti­fikate aus­zustellen, kann Power­Shell diese Auf­gabe seit Windows 8 und Server 2012 mit New-SelfSignedCertificate über­nehmen. Sie lassen sich etwa für die Client- und Server-Authenti­fizierung oder die Code-Signierung ver­wenden.

Um die Authen­tizität von Scripts zu gewähr­leisten, kann sie PowerShell mit einer Signatur versehen. Dies ist eine Voraus­setzung dafür, um stren­gere Richt­linien für die Aus­führung von PowerShell-Code vorzu­geben. Das erfor­derliche Zerti­fikat kann man bei intern ent­wickel­ten Scripts über eine AD-basierte CA aus­stellen.

Die Ausführung von PowerShell-Scripts lässt sich über Richt­linien ein­schränken, standard­mäßig wird sie blockiert. Während die vom Admin interaktiv gesetzte Execution Policy von jedem User aufge­hoben werden kann, ist die Konfi­guration per GPO nach­haltiger. Sicher­heit gegen bös­willige User bietet sie aber trotz­dem nicht.