I am running a root Enterprise CA by itself on a machine that is not also a domain controller on Windows 2008. I am getting the following errors: EventID 87 (CertificationAuthority) Active Directory Certificate Services could not use the default provider for encryption keys. Keyset does not exist 0x80090016 (-2146893802) EventID 86 (CertificationAuthority) Active Directory Certificate Services could not use the provider specified in the registry for encryption keys. Keyset does not exist 0x80090016 (-2146893802) Everything else seems to be working correctly - I'm not sure what effect these errors are having... I'm also getting errors when I drill down Roles -> AD CS -> Enterprise PKI -> <CAname>: AIA Location #2 Unable To Download CDP Location #2 Unable To Download Last week, I performed an in-place upgrade of the OS hosting my CA from 2003 to 2008 and everything seemed good. I tried to reduce the lifespan of the certificate from 10 years to 7 years using a CAPolicy.inf and was unsuccessful. I ended up renewing the root certificate several times in the process; once choosing to generate a new key. I don't know if any of this has anything to do with it, but I figured I'd mention it. Thanks in advance for any assistance.

It sounds like the CA is hosed up and cannot find the key material protected by your chosen CSP.1) What CSP are you using2) What are the AIA and CDP locations that are failing? HTTP or LDAP?3) if you look at the local machine store for the Certificates console, do you see each of the CA certificates? Does it state that you have the privatekey associated with the CA certificate.4) WHat backups did you take of the CA database and keys before the migration, can you restore back to that point in time>?Brian

1) This was left at default. Under HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CAname>\CSP, the Provider key says "Microsoft Strong Cryptographic Provider 2) A third errored entry has now shown up - DeltaCRL Location #2 - but all 3 are HTTP 3) I do see quite a few certificates in the local store, and each says, "You have a private key that corresponds to this certificate". Unfortunately there are quite a few certificates in there because I was trying several things to change the lifespan of the root cert and every time I did it, it looks like it issued a new certificate (when I renewed). 4) My CA is a virtual server, so when I upgraded to Win2008, I backed up the old virtual hdd first and then performed the in-place upgrade, so if I wanted to, I could shut down this one, bring the old one back up and theoretically everything would be back to before I performed the Win2008 upgrade.

It sounds to me like you have either SSL enabled or the Web site is not firing.Start troubleshooting in the IIS console and first check whether SSL is enabled for the /CertEnroll folder.Also, try copying and pasting each link into IE and testing the URL. (Also try as https rather than http)Brian

I do have SSL enabled - I didn't even think about that. How do I set them to go to HTTPS? They all work under https in IE. Also, When I right-click the CA and go to Properties -> General tab, I see Certificates 0 thru 6 for a total of 7 certs. Should I (can I?) clean out those old certificates to make things cleaner? Under Roles -> AD CS -> Enterprise PKI -> <CAname>, on the right hand side, the URLs seem to be pointing to a number of different certs. Several say <CAname>(5) and one says <CAname>(6). I feel like the whole CA is very confused right now because I renewed the Root cert so many times. Thanks for your help. **EDIT** - I went in and un-checked "Require SSL" on the CertEnroll folder only and the errors disappeared... am I sacrificing security this way or is that the only way to do it?

You are not sacrificing security!!!You cannot use SSl to protect the CRL and CA certificate download sites as you are setting up a chicken and the egg issue.1) I need to download the CRL2) I need to verify the SSL certificate before I can do that3) To verify the SSL certificate, I need to download the CRLRepeat steps 2 and 3 forever and ever.After the release of KB 02-48, SSL is no longer supported for CRL and CA certificate download. These are public documents with no privacy information, so they should never have SSL enabled for downloadBrian

Thanks - everything looks good now. Am I hurting anything by having all those old Root Certs in there? Like I said I now have 7 root certs (0 thru 6) in the list...

It kind of sucks if you get audited <G>. Also, if you have issued certificates in between, then you have many CRLs to maintain (Each one is unique for each key pair used, and must be available for revocation checking.Brian

Is there any way to "clean it up" per-se? I have deployed certificates to VERY few machines at the moment and could easily re-deploy to what is already out there.

Roll back to your previous image and do the upgrade again, replacing the issued certificates. Only renew a single time (not six times). Fix the SSL problem as wellBrian

I see... well thanks for your help.