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

The client authentication cert issued to the FQDN of the host under Local Computer>Personal>Certificates client certification path requires the PKI root cert to be deployed.

As noted, this is only true for PKI issued certs and not self-signed certs as self-signed certs don't have root authorities.

To clarify, when I look in certmgr under Local Computer>Trusted Root Certification Authorities>Certificates on a MECM client, all of the root certs are either set to <All> or to something more specific such as Time Stamping for Intended Purposes.

Ah, OK. That purpose simply calls out what purposes are valid for certs issued by that CA and have no true impact or significance.

Should the PKI deployed root cert deployed be left to <All> for intended purposes or set to something more specific such as only server and client authentication?

That's determined by the PKI's configuration as noted and is not something you should change. The purpose is metadata set when the root CAs cert is imported into the system. As noted, it's based on the certs eligible to be issued by that CA/PKI. Changing it limits systems from trusting certs issued by that PKI based on the purpose of the cert which in general probably is not desirable. Bottom line is to not change anything about the root CA's cert.

Answer 2

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 3

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.

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,

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.