If you happen to use SCCM (System Center Configuration Manager aka ConfigMgr) any version with client TLS or even server TLS certificates based on CNG (Cryptography Next Generation) aka KSP (Key Storage Provider) certificates, it will not work. Config manager supports only the "legacy" CSP certificates. I have already covered the "new" CNG/KSP certificate providers in two articles (here and here) and both times I stressed the fact that a lot of applications do not support these new APIs (althoug they are built-in since Windows Vista).
Yet certificate templates call them "Windows 2008 template" while they deprecate the older CSP (Cryptographic Services Provider) technology naming it as "legacy". That makes a lot of people use the "new" CNG/KSP templates instead, arriving at painful problems. Just as I have experienced last friday again :-) and spent 4 hours troubleshooting what I have already known :-(
What are the symptoms?
For example, if you use CNG/KSP based TLS/SSL server certificates on server, although it works with IIS, it does not work with SCCM client/agent registration. It does not work because the SCCM MP (management point) which registers the SCCM client must encrypt a registration response message for the client while it cannot use the new CNG/KSP API and fails such an operation. SCCM client/agent side will then contain the following error messages in ClientIDManagerStartup.log log file in %systemroot%\CCM\Logs:
RegTask: Client is not registered. Sending registration request
RegTask: Reply for registration was empty. Error: 0x8000ffff
The SCCM server with the client assigned management point (MP) that the SCCM client uses for its registration may have the following error messages in MP_RegistrationManager.log log file in %programfiles%\SMS_CCM\Logs:
MP Reg: Registration body is invalid
MP Reg: Registration failed
MP Reg: Failed to send reply. Error: 0x80090014
If you do not see the detailed error messages, you may have to enable SCCM debug logging for the ConfigMgr component in tegistry:
Enabled = REG_SZ = True
Or you can enable the config manager debug logging globally for all components the following way:
Enabled = REG_SZ = True
Note: do not forget to disable the debug logging again after you finish your troubleshooting!
How to determine what API or which provider manages private keys for config manager certificates?
If you want to make sure the SCCM server or SCCM agent/client uses certificates based on (correctly) CSP instead of (incorrectly) CNG/KSP, you must determine what crypto provider manages private keys for the certificates. All certificates will be visible in Certificate MMC console and will display as valid, while the console does not distinguish between providers and does not display any information regarding the provider type. The only way to determine the type of cryptographic provider hangling a particular certificate's private key is by using command line:
certutil -repairstore my *
This command displays each certificate in computer's personal (my) certificate store together with the crypto provider which manages its private associated private key. If the provider's name is something ending with Key Storage Provider, then the certificate is CNG/KSP certificate which is not supported for configuration manager. While all other providers mean the "legacy" CSP certificate which is actually supported for config manager.
If you create certificates for SCCM by using internal AD CS (Active Directory Certificate Services), always use certificate templates either version 1 (Windows 2000) or version 2 (Windows 2003), do not use certificate templates of version displayed as Windows 2008 or configure their properties on Cryptography tab to use the Legacy cryptographic service provider intestead of the unsupported Key storage provider if this option is available and configurable in your GUI.
If you buy certificates from a public certification authority (CA), make sure you create the custom certificate request by using the legacy key instead of the CNG key which is not supported by SCCM.