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.
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.
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:
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.
On the Details tab, scroll down to and select the Thumbprint item in the list box.
Copy the thumbprint from the details pane in the dialog.
Press OK to close the open Certificate dialog.
For a certificate stored in a file (like the .CER file extracted above):
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):
Open the created .CER file with Notepad.
Copy the lines between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----.
For a certificate stored in your Personal certificate store:
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.
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.
03/14/22: PowerShell formatting fix to include a parenthesis.