Recently I worked with a client who had a series of internally written custom powershell scripts they wished to seamlessly run on their autopilot built Microsoft Endpoint Manager (MEM) managed Windows 10 machines.
They wanted to sign these scripts with a Certificate from their Internal Public Key Infrastructure (PKI). Why would you want to run signed scripts? Well, to only run scripts from a verified and trusted source, and also to verify that a script running has not been tampered with in any way.
This post is not intended to go in to the mechanics of creating and publishing a code signing certificate, nor signing the script, nor through the details of deploying Code signing certs via GPO, changing execution policies or pushing PowerShell scripts via MEM as these are relatively well documented. This post briefly outlines the steps required to deploy a code signing certificate from an internal PKI to non domain joined, to MEM managed Windows 10 machines.
The basic steps are, at a high level:
• Create and publish an appropriate code signing certificate on your issuing CA(s).
• Request a code signing certificate (note: it’s a user certificate).
• Using powershell, sign the script with the Code Signing Certificate you have enrolled for.
• Ensure that you also have Trusted Profiles working in MEM to deploy the root and issuing CA certificates (chain of trust) for the code signing certificate you will be deploying.
• Ensure that you have set an appropriate powershell execution policy on your Windows 10 Devices that will allow running of signed scripts (for example AllSigned – can be achieved using “Administrative Templates” Template in MEM)
At this point, with the above in place if we tried to run the signed script on a new standalone MEM managed machine, we would get prompted as to whether the certificate was trusted or not. Saying yes would install the certificate that the script is signed with in to the “Trusted Publishers” store on the local machine.
To streamline and take out the need for accepting a prompt to trust the publisher, in the old world of Group Policy we could export our code signing certificate used to sign the script and configure a GPO to distribute this certificate in to the “Trusted Publishers” store on each domain joined machine that falls under the scope of that policy. The signed script (assuming the Powershell execution policy is set appropriately) will just run as it is trusted.
However, with the clients current build being configured via autopilot and Windows 10 PCs not domain joined, how do we achieve the same result? By creating a custom profile in MEM.
Firstly, find the Thumbprint of your code signing cert
Get-ChildItem -Path Cert:\CurrentUser\My
This will be used to then show the contents of the certificate in a string, for feeding into an MEM Profile. Then run (replacing thumbprintfrompreviouspowershell with the actual thumbprint):
[System.Convert]::ToBase64String((Get-Item -Path Cert:\CurrentUser\My\thumbprintfrompreviouspowershell).RawData, ‘InsertLineBreaks’)
Copy both the thumbprint, and the whole certificate string in to a text file for later – Armed with these two things, we can create a custom profile in MEM
Select Devices > Configuration profiles > Create profile
Choose the platform of your devices. In our example, Windows 10 and Later, and from Templates choose “custom”
Give the Custom Profile a name and a description
Click Add, to add configuration settings
Name: Something Meaningful to Identify the Certificate to you
OMA-URI: ./Device/Vendor/MSFT/RootCATrustedCertificates/TrustedPublisher/<code signing cert thumbprint>/EncodedCertificate
Data type: String
Value: The string – base 64 encoded version of the certificate (with no line breaks)
For example:
This can then be assigned to an appropriate group in MEM, and shortly after, you should see the certificate in the Trusted Publishers store on the machines in scope.
Check on the Windows 10 PC check the local certificates, in the trusted publishers store:
Note – in MEM, the profile assignment status may show an error, even though the Certificate has been successfully deployed to the PC; this seems to happen frequently and is potentially an MEM bug.
