Just an update on this issue - Someone suggested that I just leave the Trusted Root CA setting in SCCM blank, and that this would allow clients with either age of certificate to register properly. Sure enough, that worked. Apparently this setting is optional, and setting it restricts which CA's are trusted to those in the list, regardless of what CA's windows is configured to trust.
However, while leaving this option blank fixed my registration issues, it broke OSD. When the Trusted Root CA setting in sccm is left blank, our OSD fails with the following: Initialized CStringStream object with string: > 3427c2f1-84d0-4eef-9f18-358352352fbc;2015-01-22T16:47:18Z. > Set media certificate in transport > Set authenticator in transport > CLibSMSMessageWinHttpTransport::Send: URL: MP.DOMAIN.COM:443 GET > /SMS_MP_AltAuth/.sms_aut?MPKEYINFORMATIONMEDIA > In SSL, but with no client cert > [TSMESSAGING] AsyncCallback(): > ----------------------------------------------------------------- > [TSMESSAGING] AsyncCallback(): WINHTTP_CALLBACK_STATUS_SECURE_FAILURE > Encountered > [TSMESSAGING] : dwStatusInformationLength is 4 > [TSMESSAGING] : *lpvStatusInformation is 0x8 > [TSMESSAGING] : WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA is set > [TSMESSAGING] AsyncCallback(): > ----------------------------------------------------------------- > Error. Received 0x80072f8f from WinHttpSendRequest. > hr, HRESULT=80072f8f > (e:\qfe\nts\sms\framework\osdmessaging\libsmsmessaging.cpp,8919) > sending with winhttp failed; 80072f8f > m_pHttpTransport->Send (0, 0, pServerReply, nReplySize), HRESULT=80072f8f > (e:\qfe\nts\sms\framework\osdmessaging\libsmsmessaging.cpp,5159) > MPKeyInformation.RequestMPKeyInformationForMedia(szTrustedRootKey), > HRESULT=80072f8f > (e:\qfe\nts\sms\framework\osdmessaging\libsmsmessaging.cpp,9410) > Failed to get information for MP: https://MP.DOMAIN.COM. 80072f8f. For the moment, I've just been switching the setting back and forth, configuring the Trusted Root CA setting with the new certificate for our CA whenever we need to re-image computers, and then deleting that certificate when done so that clients can communicate with the server. Obviously, that's not a long term solution. I think my next options are to either open a support incident with MS, or to try and put together some kind of startup script to renew computer certificates signed by the old CA cert. In the meantime, if anyone has a better suggestion (or an existing script for the certificate renewals), I'd love to hear it. Steve On Tue, Jan 6, 2015 at 4:06 PM, Steve Whitcher <st...@whitcher.org> wrote: > After rebuilding my workstation recently, I couldn't get it to register > with the SCCM server properly. Eventually I found warnings in the > SMS_MP_Control_Manager component which pointed me to the issue. The > warnings read: > > *MP has rejected registration request due to failure in client certificate > (Subject Name: COMPUTER.DOMAIN.COM <http://COMPUTER.DOMAIN.COM>) chain > validation. If this is a valid client, Configuration Manager Administrator > needs to place the Root Certification Authority and Intermediate > Certificate Authorities in the MPÆs Certificate store or configure Trusted > Root Certification Authorities in primary site settings. The operating > system reported error 2148204809 <2148204809>: A certificate chain > processed, but terminated in a root certificate which is not trusted by the > trust provider. * > > A couple of months ago, I renewed our root CA's certificate, as the old > one expires in under 2 years. After renewing the cert, I never updated the > root CA cert in the SCCM site settings. Thus, any computers that were > re-imaged or otherwise issued new certs since the update, have been getting > rejected by SCCM. > > I updated the trusted root CA in SCCM site settings yesterday, and today > my workstation has registered successfully with the server, along with many > others that had been affected by the same issue. However, I'm still seeing > some instances of the same error in the logs, for other computers. Looking > at a couple of examples, it looks like computers which have certs signed by > the OLD CA certificate are now getting registration requests rejected. > > As far as I can tell, I can't have both the new and old root CA certs > trusted by SCCM. The dialog for choosing a cert looks like it can accept > multiple root CA certificates, but when I added the new one it replaced the > old cert, rather than leaving both of them trusted. > > What am I doing wrong here? How can I get SCCM to talk to computers > regardless of whether the certs are signed by the old or new CA cert? > >
