This script signs a PowerShell script with a code-signing certificate from the current user certificate store. It first searches for a certificate that matches the configured certificate name, checks whether it is still valid, and then applies a digital signature to the selected script. After signing, it writes a CSV log entry so the signing activity can be tracked later.
How the script works
The script starts by asking for the full path of the PowerShell file that should be signed. It then searches the current user certificate store for a certificate that has the code-signing flag and whose subject matches the configured name pattern. In this case, the certificate is selected by checking the subject text, for example with a filter such as *coding*.
If no matching certificate is found, the script stops immediately. If a certificate is found, the script checks whether it is still valid by comparing the expiration date with the current date. Only a valid certificate is used for signing.
After that, the script checks whether the target PowerShell script exists. If the file is available, the script signs it with Set-AuthenticodeSignature. Finally, it writes a log entry containing the date, time, file path, certificate subject, thumbprint, expiration date, user name, and computer name.
Selecting the signing certificate by name
A key part of the script is the certificate selection logic. The script does not just pick any certificate from the store. Instead, it filters for a code-signing certificate and then matches the certificate subject by name. This is useful when several certificates exist in the user store, because it helps ensure that the correct certificate is used for signing.
For example, this line searches for a code-signing certificate whose subject contains the text coding:
powershellGet-ChildItem Cert:\CurrentUser\My -CodeSigningCert | Where-Object { $_.Subject -like "*coding*" }
That means the certificate must meet two conditions:
- It must be a code-signing certificate.
- Its subject name must match the text pattern defined in the script.
This approach is practical when a dedicated signing certificate has a recognizable subject name. It also makes it easier to distinguish between multiple certificates in the current user store.
Trusted publisher requirement
The signing certificate must also be trusted on the target system. In many environments, the public certificate is added to the Trusted Publishers store so Windows and PowerShell recognize the script as coming from a trusted source. The issuing CA chain should also be trusted. If the certificate is not trusted, the script can still be signed, but users may see warnings about the publisher not being trusted.
What you need
To use the script successfully, you need:
- A valid code-signing certificate in the current user certificate store.
- A certificate subject name that matches the selection filter in the script.
- A target PowerShell script file that exists at the entered path.
- A writable log path for the CSV logging entry.
- A trusted certificate chain, and ideally the certificate in the Trusted Publishers store.
Why this is useful
Digitally signing PowerShell scripts helps confirm that a script has not been changed after signing. It also improves trust in environments where execution policies or security controls require signed scripts. For administrators, this is especially helpful when scripts are stored centrally and distributed across systems.
Example use case
A practical example is signing internal administration scripts before they are placed into a shared repository or deployed to managed systems. The script can be used locally by an administrator with a personal code-signing certificate, and each signing action is documented in the log file for auditing.
GitHub download
Download the script here: GitHub repository