Duplicate root certificates on MECM clients an issue?

Question

Is there any sort of issues or security risks that can occur with a duplicate root certificate (Intended Purposes is All) deployed to Windows clients/servers from an internal PKI infrastructure?

For MECM root certificates, it's not clear in the below link if the intended purposes should be set to All or something more specific such as client authentication only if someone can clarify and possibly send a link that is more detailed on MECM root certificate configuration configuration/requirements.

https://learn.microsoft.com/en-us/mem/configmgr/core/plan-design/network/pki-certificate-requirements

Auto enrollment seems to be failing on some clients and an option is to use a GPO as a backup method to make sure clients receive the root cert. Targeting the GPO to only clients that are missing the cert is possible but adds more management overhead. A configuration item/baseline deployment may be another option, but this may not work on clients that are not receiving the root cert.

Answer 1

I'm confused by your statement "ConfigMgr doesn't manage certificates"

This statement is accurate in the context of your question because self-signed certificates are automatically trusted and there's no such thing as a root CA or certificate for a root CA when using self-signed certs (in ConfigMgr or anywhere else). So that begs the question here: are you using PKI-issued client auth certs for ConfigMgr or not?

Is there some sort of white paper that has better documentation on MECM and PKI certificate integration in an environment that has Internet-only clients that may occasionally connect to VPN?

No, the two aren't specifically related topics.

A handful of facts here may help as I think you are conflating multiple, disparate things here:

• The ConfigMgr client always uses a client auth certificate to communicate with the site. This cert can be self-signed or issued from a separate PKI.
• The underlying path (i.e., VPN, intranet, Internet) for client communication is irrelevant for cert choice, i.e., the client won't choose to use a different type of cert based on the data path. The client always chooses the most secure certificate type available to it (which is a PKI cert if it's available and trusted).
• Self-signed certs are also self-generated and automatically trusted since they are self-generated. There's no hierarchy, PKI, or root CA involved.
• Trust for PKI-issued certificates is established (in Windows) by adding CAs in the PKI hierarchy to the trusted root CA and intermediate CA stores. With an Enterprise (aka AD integrated) PKI this is done automatically for you on domain-joined devices. When your PKI is not AD integrated, the device is not AD joined, or there is no connectivity, then making the PKI trusted is a challenge without an automatic solution in most cases although you can use SCEP if the systems are managed by Intune to issue a cert and establish trust.
• PKI certificate trust is an OS function and not a ConfigMgr function.,
• All certificates "used" by a system must be trusted. For a ConfigMgr client, that means the local client auth cert as well as the server auth cert for any of the site roles it communicates with must all be trusted.

Answer 2

Sorry, can you add some clarity here, please.

Specifically, ConfigMgr doesn't manage certificates so I'm not sure what you mean by " MECM root certificates". Root certs also don't have "intended purposes" so not sure what you are calling out there. Issued certs have intended purposes. To be clear "root cert" implies the certificate for the root certificate authority. If you are simply referring to the individual client auth cert for each managed device, that's exactly as documented and should include "Client authentication"; it technically could include more, but it's a generally bad practice to include anything more than what's needed as this creates ambiguity and opens the door for the cert to be used for unintended purposes.

Additionally, what do you mean by duplicate root certs? As noted, "root cert" implies a cert from a root CA. Do you have multiple PKIs? Is your PKI (or are your PKIs) AD integrated? How are you expecting clients to get the cert for the root CA if not? If your PKI is AD integrated and they are not automatically getting the root CA added as trusted, then trying to do so with a GPO will probably also fail as that's the same mechanism that adds it as trusted in the first place and thus you need to troubleshoot why this is failing in the first place.

Also, if the device isn't managed by ConfigMgr because there's a PKI trust issue, then using CI won't work either -- chicken, meet egg.

Ultimately, adding the same cert from a root CA to the trusted root CA store will have zero negative impacts -- it's completely benign -- but you really should troubleshoot why these devices aren't getting the cert for the root CA in the first place.

Answer 3

Hi,

Thank you for posting your query.

Kindly follow the steps provided below to resolve your issue.

Use the information in this article to help you set up security-related options for Configuration Manager. Before you start, make sure you have a Plan for security.

Important

Starting in Configuration Manager version 2103, sites that allow HTTP client communication are deprecated. Configure the site for HTTPS or Enhanced HTTP. For more information, see Enable the site for HTTPS-only or enhanced HTTP.

Go to this link for your reference and other troubleshooting procedures https://learn.microsoft.com/en-us/mem/configmgr/core/plan-design/security/configure-security

------------------------------------------------------------------------------------------------------------

If the answer is helpful kindly click "Accept as Answer" and up vote it.

Answer 4

I also confirmed the windows client computer cert (client authentication) within the Personal certificates store (computer) issued certification path on a client requires the root cert.

The Microsoft documentation says "Use PKI certificates whenever possible" and required for internet-based site systems so it seems depending on a root cert is required vs. using only MECM generated self-signed certs in this scenario.

Answer 5

Hi @jeanne laird , From your description, it seems you are configuring a software update point to use TLS/SSL with a PKI certificate. we request web server certificate for Configuration manager used to encrypt data and authenticate the server to client. We also use GPO to auto enroll the client certificate for windows computers which is used to authenticate Configuration Manager client computers to site systems. After the client certificate is installed, we get the 0x800b0109 error which indicates the root CA certificate is not installed on these clients. If there’s any misunderstanding, feel free to let us know.

In fact, to make the client certificate work, the CA certificate is also needed to install on the windows client computer to ensure the client certificate is published via a trusted CA. For example, if there’s only one Enterprise Root CA in your environment, we need to install the Root CA certificate to “Trusted Root Certification Authorities” store. If there’s any intermediate CA in your environment as well, we also need to install these CA certificate into “Intermediate Certification Authorities” store. (The following is a certificate published from a PKI environment with two CAs)

I notice you have resolved the error by manually installing the Root CA certificate into the “Trusted Root Certification Authorities” store. It seems our environment is only with one Enterprise Root CA. Then we just need to install this one on all the windows clients.

To deploy the Root CA certificate to some windows client devices, we can do it via GPO. We can configure a GPO, set Computer Configuration\Policies\Windows Settings\Security Settings\Public Key Policies, right-click Trusted Root Certification Authorities, import the Root CA certificate. Then link the GPO to the OU or the domain the devices belongs to. Here is a link with the detailed steps to configure the GPO for your reference:
https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/distribute-certificates-to-client-computers-by-using-group-policy

Meanwhile, I notice you have question with duplicate CA certificate. Based as I know, the Root CA certificate we export via Client computer or Root CA is the same. So I think import multi times will not have any impact.

In addition, to know more about PKI certificate, here is a link you can read to get more information.
https://learn.microsoft.com/en-us/mem/configmgr/core/plan-design/network/example-deployment-of-pki-certificates#BKMK_overview2008

Hope the above information can help.

Best regards,
Cherry

---

If the response is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.