Blog Post

Security, Compliance, and Identity Blog
2 MIN READ

Known Issue: Logging Information for Native Mode Certificate Selection

yvetteomeally's avatar
yvetteomeally
Icon for Microsoft rankMicrosoft
Sep 08, 2018
First published on CloudBlogs on Dec, 15 2009

[ Carol Bailey has contributed today's post]

A couple of issues recently came to our attention from the TechNet forums with regard to native mode certificate selection when there is more than one available certificate that could be used:

  • When a certificate in the certificate store has expired, we log this and Trace32 highlights it as an error, which might be interpreted that it is this certificate that is selected.  This can lead customers to think that their certificate selection criteria isn't working, whereas in fact we always log this condition, even when Configuration Manager has selected a different certificate that is successfully used for native mode.
  • The logging information, even with verbose debug enabled, does not identify which certificate was selected by Configuration Manager.  Only the certificate thumbprint can uniquely identify a certificate, and this is not logged in ClientIDManagerStartup.log or any of the other client logging files.

The first issue can be put down to "logging noise" that can be either safely ignored, or downgraded to information only.  There might be good and known reasons why the certificate store contains expired certificates.  Obviously, native mode communication in Configuration Manager requires an unexpired certificate, but the presence of an expired certificate will not prevent Configuration Manager from working.  The error that you see looks like this: The certificate issued to ‘<computer_name>' has expired.

The second issue is of more importance because there could be good reasons why you need to know which certificate Configuration Manager has selected when using your certificate selection criteria.  For example, it might successfully select a certificate that is not trusted by the native mode site systems because it chains to a different root CA.  Another example is that the selected certificate might contain CRL paths that are inaccessible to the native mode site systems, and this results in a CRL checking failure.

We've filed a design change request (DCR) to improve the logging information for future versions of the product, but in the meantime, if you need to confirm which native mode certificate was selected by Configuration Manager, consider running the script that Gabe Brown posted on his blog: Getting a ConfigMgr Client's Registered Certificate Thumbprint .  Although this script is provided "as is", it is a nondestructive script to run on the client to read the certificate thumbprint selected by Configuration Manager and displays it on the screen.  Many thanks to Gabe for helping me to investigate this, file the DCR, and provide an interim solution for CSS and customers.

-- Carol Bailey

This posting is provided "AS IS" with no warranties and confers no rights.

Published Sep 08, 2018
Version 1.0
No CommentsBe the first to comment