Code Integrity Policy error for incorrectly signed MsSenseS.exe RRS feed

  • Question

  • Hello,

    i am trying to set up a Code Integrity Policy for a VM in Azure. When putting it in audit mode I faced this 

    Code Integrity determined that a process (\Device\HarddiskVolume2\Program Files\Microsoft Monitoring Agent\Agent\MonitoringHost.exe) attempted to load \Device\HarddiskVolume2\Program Files\Microsoft Monitoring Agent\Agent\Health Service State\Monitoring Host Temporary Files 34\23\MsSenseS.exe that did not meet the Enterprise signing level requirements.

    unexpected error in the event log, even though the corresponding intermediate certificate is explicitly trusted in the policy. The XML snipped of the root certificate looks as following (and is later referenced as allowed signer):

    <Signer ID="ID_SIGNER_S_55DB7_0_0_0" Name="Microsoft Development PCA 2014">

    <CertRoot Type="TBS" Value="2C867DFC78230D5E14EC8C5DD18420A30C8E26E5BDE32CE780325013D473944F" />

    <CertPublisher Value="Microsoft Windows" />


    I investigated the signature attached to the MsSenseS.exe and found two potential problems:

    First: According to the Digital Signature Information of the file "A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.". This information refers to the root certificate "Microsoft Development Root Certificate Authority 2014", which is not automatically trusted in Azure VMs.

    Second: The leaf certificate is expired (valid from 06/07/2017 to 02/07/2018) and not timestamped.

    What leads to this error message, the expired and non-timestamped leaf certificate or the untrusted root certificate? Also if I'd open a support request, would you classify it as a bug?

    Kind regards,

    Daniel Ostovary

    • Edited by Daniel Ostovary Thursday, January 17, 2019 5:07 AM Corrected bullet points, made error message italics
    Tuesday, January 15, 2019 7:10 AM

All replies

  • As checked on February 1 2018 the MsSenseS.exe apparently is now timestamped and the root certificate is trusted by default in Azure VMs. I assume there won't be any error by the Code Integrity Policy any more. Therefore this thread is resolved.
    Friday, February 1, 2019 6:17 AM