We have ConfigMgr 2012 R2 SP1 deployed with over 200 distribution points and around 45000 clients.  The environment is configured for HTTPS or HTTP, and a Root CA is specified in the settings. (Clients use PKI certificate when available)

Our Offline Root CA was recently migrated from server 2008R2 to 2012R2.

Our client certificates have the following Path:

• OFFCA01 (offline CA)
• CS01 (Issuing CA)
• Client Certificate

Our offline CA cert is imported into SCCM for client authentication etc.  During the migration, the Offline CA thumbprint was changed.  As a result, 'New' devices are now untrusted and end up with Client = No in the console.

Existing devices are continuing to function as per usual, as they still have the old cert (there has not been a forced re-enrollment).

How do I remedy this?  I can't import both OFFCA's into Site Settings.  Both OFFCA's are already in Trusted Root Certification Authorities and Intermediate Certification Authorities.

If I update SCCM's config to the new OFFCA then all the existing clients will not function until they receive a new certificate.  There is also the impact of updating all the DP certificates and IIS certificates too.

Why can't SCCM trust both certificates?

Why can't SCCM trust both certificates?

Does it really matter why? That's just the way it is.

Are you using OSD? If not then you can leave the field blank. If are using OSD, then your only recourse is to reissue all the certs -- impact or no impact, there's not much else you can do. You should file this on connect.Microsoft.com though.

Ultimately, to my knowledge, the thumbprint should not have changed unless you updated the cert with a new key (but that doesn't really matter now). Total side question here though (something else you can't change now either): why upgrade an offline root CA at all? Who cares what OS it is running -- it's off 99.99999% of the time and if done correctly, never ever on the network.

Hi Jason, Thanks for the reply.

We are using OSD, and your comments are exactly what I was thinking.  We have opened a case with MS PS and will see how it progresses.

I'm unsure why we upgraded the OS of the root CA, but I do know that it was on VMWare and we are in the midst of a migration away from that to Hyper-V.  As a result, it was probably determined that upgrading the OS at the same time might have made sense.  I'm not too sure though.

Nonetheless, we now need to cut the cert over, but do so in a manner with the least impact.  I'll leave that with MSPS :)

(the same cert is also used to authenticate our wireless devices)