Adding a Certificate to Trusted Publishers using Intune

[Intune Support Team]

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.

1. The code-signing certificate you wish to add.
2. The base-64 encoded version of the code-signing certificate.
3. 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:

1. Right-click on the signed file and choose Properties.

2. Choose the Digital Signatures tab. If this tab does not appear, then the file is not signed.

3. Choose the appropriate signature from the Signatures list and then press the Details button. Most files will only have a single signature.

4. In the Digital Signature Details dialog, choose View Certificate.

5. In the Certificate dialog, choose the Details tab and press Copy to File.

6. 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.

7. 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:

1. 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.
2. 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-Lis​t

      
      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:

1. 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.
2. 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.

1. Follow the instructions at Create a profile with custom settings in Intune to create a new, custom, Windows 10 device configuration profile.
2. 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
      
      
3. 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.

[Jan Gutjahr]

Hi Jason,

Much appreciated post, thanks for documenting and formalizing this process!

When I tested this same approach I noticed that the base-64 encoded version of the certificate (the really long value between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----) seems to only work if it does not contain any linefeeds etc. Using a tool like Notepad+ these can easily be removed by searching for '\r\b' and replacing it with an empty string ''.

The CSP documentation mentions this ('The Base-64 string value cannot include extra formatting characters such as embedded linefeeds, etc. '), but it might be useful to call this out to make sure people don't trip over that.

Regards,

Jan

[Jason_Sandys]

Hi Jan. Thank you for the comment. You are 100% correct and I've slightly adjusted the post above to reflect this. Thank you.

[Sander de Wit]

This works as designed, however the reporting in Intune gives some errors.

This happens in multiple tenants. any idea what causes this?

EncodedCertificate [./Device/Vendor/MSFT/RootCaTrustedCertificates/TrustedPublisher/<thumbprint>/EncodedCertificate]

STATE
Error
ERROR CODE
0x87d1fde8
ERROR DETAILS
Remediation failed

[kim oppalfens]

Hi Jason,

Looks like something went wrong with the command to retrieve the Bae64 from a cer file. I believe the opening bracket is missing.

I believe the new method is something added in later .Net versions, so that could be another challenge.

This command did work for me:

[System.Convert]::ToBase64String(([System.Security.Cryptography.X509Certificates.X509Certificate2]::CreateFromCertFile("<path_to_certificate>")).Export('Cert'), 'InsertLineBreaks')

Best,

Kim

[Intune Support Team]

Hi @kim oppalfens, the post has been updated with the missing bracket. Thanks for the feedback!

[rahuljindal]

Just like @Sander de Wit , I am also experiencing error 0x87d1fde8 (Remediation Failed). However, the policy is getting applied successfully. Is this a known issue with this particular CSP @JasonSandys or @IntuneSuppTeam?

[Zeddoo]

I see the same thing as @rahuljindal where I pushed it, I see it successfully drop the cert on the machine but on Intune it says Remediation Failed with error code 0x87d1fde8.

[alexbal]

Nice article thanks!

Is there a way to trust *all* code signing certificated my enterprise CA has created (we have one per user so we know who edited last signed file).

In the current case I am signing all my PowerShell scripts used for scheduled tasks. They are stored in sysvol and thus considered untrusted.

I signed the PowerShell script with a users code-signing cert.  The scheduled tasks are run by NTAUTHORITY\SYSTEM,

I tried adding the CA cert via GPO to the trusted publishers machine store and that doesn't seem to have worked and generates a 'rejected by administrator' alert in task scheduler.

Logging on as domain admin to the machine where the task is to run and manually running the PowerShell script results in the untrusted publisher notification and asking me if i want to trust it.

Do I really have to add every code signing cert in the enterprise to trusted publishers? 

[Intune Support Team]

Hi @Sander de Wit, @rahuljindal, @Zeddoo, thank you for your comments, we're looking into this and will get back to you on this.

[Jason_Sandys]

Hi @alexbal,

I'm assuming you are wanting to have all of the certs added as trusted publishers and not just trusted (as there is a difference). For this, no, there is no way to do this except individually. Adding the cert from the root CA that issued these certs to the trusted publishers store has no effect. Thus, yes, you must add each individual cert used for code-signing to the trusted publisher store. With group policy, this is pretty easy and with the above method, it's also pretty quick in Intune. With a little bit of effort, the above can also be fully automated using the Graph API to create the profile and run against multiple certs with minimal manual effort.

[scyto]

@Jason_Sandys thanks for confirming the as-designed behavior, i will stop banging my head against that wall.  This is for a small home lab so i can do that easily (there is only me!). (oops this is alexbal, wasn't paying attention to which account i was using)

However it occurred to me that in an IT pro shop when scripts change a lot, by many individuals, one would have to implement a secrets vault and make signing hard to use the one long lived cert and if the cert was compromised or more likely an admin went rogue one has to re-sign everything.

If one could issue per-admin code signing certs then just the rogue admin's certs could be revoked.  But for this to be feasible from a management perspective one wouldn't want to distribute potentially hundreds of certs - especially for machines nor domain joined.... (i only learnt about the intune cert connector today, and have no clue how that would work on say, linux).  Was just a thought, can't help being a PM :)