Adding a Certificate to Trusted Publishers using Intune

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.

By Jason Sandys – Sr. Program Manager | Microsoft Endpoint Manager

Two significant actions on Windows devices require code-signing using a trusted, code-signing certificate:

Third-party application update installation (for updates injected into the WSUS catalog by tools like System Center Updates Publisher or the native third-party updates feature in Microsoft Endpoint Configuration Manager)
Running a PowerShell script

In the case of third-party application updates, the tool used to inject the updates into the WSUS catalog signs the updates using a code-signing certificate that you provide. This signing is strictly required and enforced by Windows.

You must manually sign PowerShell scripts; this is also strictly required and enforced by Windows if the system's execution policy mandates this. See about signing in the PowerShell documentation for more details on script signing and the execution policy. See Hey, Scripting Guy! How Can I Sign Windows PowerShell Scripts with an Enterprise Windows PKI? for a detailed step-by-step of signing a script.

In addition to Windows trusting the code-signing certificate used to sign third-party application updates and PowerShell scripts, the certificate must also exist in the Trusted Publishers certificate store on systems installing the third-party update or running the PowerShell script. Adding a certificate to the Trusted Publishers store for a Windows device using Intune is straight forward but involves a few steps as outlined below.

What's needed

You need the following three items to add a certificate to the Trusted Publishers store using Intune.

The code-signing certificate you wish to add.
The base-64 encoded version of the code-signing certificate.
The thumbprint of the code-signing certificate.

You do not require the private key for the certificate; you only need the private key when signing a file including scripts and third-party updates.

The code-signing certificate

If you do not have a copy of the code-signing certificate, you can extract it from a file previously signed by the certificate using the following steps:

Right-click on the signed file and choose Properties.
Choose the Digital Signatures tab. If this tab does not appear, then the file is not signed.
Choose the appropriate signature from the Signatures list and then press the Details button. Most files will only have a single signature.
In the Digital Signature Details dialog, choose View Certificate.
In the Certificate dialog, choose the Details tab and press Copy to File.
Complete the Certificate Export Wizard to create a CER file containing the certificate. Choose Base-64 encoded x.509 (.CER) for the Export File Format.
Press OK on the three open dialogs.

Code-signing certificate dialog boxes

Thumbprint of the certificate

A certificate's thumbprint is a dynamically computed identifier that uniquely distinguishes it from other certificates. You can retrieve the thumbprint of a certificate in various ways, including the following:

From the properties of the certificate. You can do this for either a certificate stored in a file (like the .CER file extracted above) or a certificate stored in the Windows certificate store:
1. Open the certificate by double-clicking the file or the certificate's entry in the MMC Certificates snap-in. You can also right-click on the certificate and choose Open from the context menu.
2. On the Details tab, scroll down to and select the Thumbprint item in the list box.
3. Copy the thumbprint from the details pane in the dialog.
4. Press OK to close the open Certificate dialog.
Using PowerShell:
1. For a certificate stored in a file (like the .CER file extracted above):
  [System.Security.Cryptography.X509Certificates.X509Certificate2]::new("<path_to_certificate>")).thumbprint
  PowerShell terminal displaying the thumbprint of certs stored in a file
2. For a certificate stored in your Personal certificate store:
  Get-ChildItem -Path Cert:\CurrentUser\My | Format-List
  PowerShell terminal displaying the thumbprint of certs stored in a Personal certificate store

Base-64 encoded version of the certificate

The base-64 encoded version of a certificate is a string-based representation of the certificate. This version contains the complete certificate but in a more portable format that is not bound to a file. Similar to the thumbprint, you can obtain the base-64 encoded version of a certain in several ways, including the following:

From a base-64 encoded .CER file (like the .CER file extracted above):
1. Open the created .CER file with Notepad.
2. Copy the lines between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----.
3. Close Notepad.
Using PowerShell:
1. For a certificate stored in your Personal certificate store:
  [System.Convert]::ToBase64String((Get-Item -Path Cert:\CurrentUser\My\<thumbprint>).RawData, 'InsertLineBreaks')
  PowerShell terminal displaying the thumbprint of Base-64 certs stored in a Personal certificate store
2. For a certificate stored in a .CER file:
  System.Convert]::ToBase64String(([System.Security.Cryptography.X509Certificates.X509Certificate2]::new("<path_to_certificate>")).Export('Cert'), 'InsertLineBreaks')
  PowerShell terminal displaying the thumbprint of Base-64 certs stored in a .CER file

The Step-By-Step Guide

To add a certificate to the Trusted Publishers store using Intune, use a custom profile and an OMA-URI to apply a setting from the RootCATrustedCertificates CSP.

Follow the instructions at Create a profile with custom settings in Intune to create a new, custom, Windows 10 device configuration profile.
Use the following values for the fields in the custom profile:
1. Name: The name of the certificate.
2. OMA-URI: ./Device/Vendor/MSFT/RootCATrustedCertificates/TrustedPublisher/<thumbprint>/EncodedCertificate
3. Data type: String
4. Value: The base-64 encoded version of the certificate without any line breaks.
  
  Intune - OMA-URI policy settings
Add scope tags and assignments as necessary.

Additional Notes

Windows systems should already trust certificates issued by a public CA. When using a certificate from an alternate source for any purpose, including those listed in this article, you need to add the root certificates for the PKI that issued the certificate to your managed Windows devices. See Create trusted certificate profiles in Microsoft Intune for steps to do this using Intune.
Through the magic of Authenticode, a signature is still valid even if the code-signing certificate used to sign a file is past its expiration date. As long as the certificate was valid when it was used to sign a file, then the expiration of the certificate itself does not impact the validity of the signature.
Driver and Windows update installation also require signing using a trusted code-signing certificate, however, either Microsoft or the hardware vendor that creates and supplies the associated files signs them. Administrators do not have to add any certificates to the Trusted Publishers store and no additional action is necessary to install either of these.
If you're not signing your PowerShell scripts and configuring an execution policy to require signing of PowerShell scripts, you should strongly reconsider your practices as this is a very important safety measure (more on this in a follow-up post).
You can also use certutil.exe for all of the operations above. Official documentation on certutil.exe is sparse, though, so this is left as an exercise for the reader if desired.

Let us know if you have any additional questions on this by replying back to this post or tagging @JasonSandys or @IntuneSuppTeam out on Twitter.