I'm looking for some clarification regarding the private key protection. My understanding is that when setting up an enterprise subordiante CA if you choose the option "Use strong private key protection features provided by this CSP (this may require administrator interaction every time the private key is accessed by the CA)" then when you go to issue a certificate you must provide a password to access the CAs private key. We are interested in leveraging autoenrollment to automate the issuing of certificates for clients computers, as well the OCSP signing certificate and CRLs would seem to benefit from autoenrollment. Will password protecting the Issuing CAs Private Key prevent AutoEnrollment? Or is the password to the private key somehow be stashed for use by the CA service?

you should not use private key strong protection for computer and CA certificates. This is because certificate services are running under LocalSystem account, so consent dialog box will appear in LocalSystem desktop session. Administrator will never see this dialog box and operation will silently fail.http://www.sysadmins.lv

Thanks much for the reply Vadims. So checking that box would not only break certificate services, but would also affect the private keys in certifcate requests - hadn't realized that! wow. So if you would checked that box would you have to run the certificate service as you own user account to receive the dialog box? or would you not run the certificate services service, and instead interactive with it via command line, in some sort of interactive mode?

I haven't tried this. Can you explain your task?http://www.sysadmins.lv

I am looking to understand how the private key for a CA can be protected. Usually clients will password protect the private key so that an unauthorized user cannot simply take the certificate file and use it. In the case of an issuing CA, they couldn't take the CA certificate and private key to setup a rogue CA to issue their own certificates. Perhaps I'm missing something with regards to private key protections, and maybe i'm thinking of this too much so as how s/mime certificates are used or how pgp private keys are protected. In relation to protecting the root CA certificate with some type of passphrase or pin, would this protection affect autoenrollment. If every certificate to be issued requires access to the CAs private key (which requires a password), then it would seem this configuration would not work with autoenrollment, unless the service can stash the password for the private key and use it in specific instances. I hope this is a better explaination. It may be the case that the private key cannot be protected with a password other than using a smartcard or HSM. Perhaps there are other protections setup within DPAPI to enhance the private key protection from being easily stolen from a CA.

You need to start researching HSMs. Software keys cannot be password protected at the CA. BTW, a smart card is a terrible idea for protecting a CA's private key as there is no way to back it up. When the smart card fails (and they do fail), that is the end of the story, you need to rebuild the CA. Brian

Thank you for the reply Brian, I'll researching HSMs.