[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:
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.
This posting is provided "AS IS" with no warranties and confers no rights.