I am looking at installing a new AD-integrated enterprise certificate authority structure, but have discovered that somebody already has created a CA (mostly used for SSL on internal websites).

I want to build the new structure according to best practices, by creating an offline root, authorizing several subordinate CAs for fault-tolerance, etc. but I don't want to mess up what's already in place. Apparently you cannot turn an existing root CA into a subordinate, so that's ruled out.

Can I simply install the new root elsewhere, not touching the existing one? (Or maybe cross-signing the existing CA with the new root's authority?)

  • I would think you wouldn't want the confusion of having two (even if it is supported which isn't likely.) Why not team with the owner of the other server to support what you need.
    – uSlackr
    Jun 2, 2011 at 17:54
  • The difficulty is that the old/existing CA was installed on a production web server used for many other things--we can't remove it from the domain, rename it, etc as M$ recommends even for migrating to a new CA.
    – ewall
    Jun 2, 2011 at 18:14

2 Answers 2


Having dealt with the same scenario, here's an overview of the approach that I took:

Get the new environment up and running, but don't give it any ability to issue certificates - use LoadDefaultTemplates=False in your capolicy.inf.

While the devices are still set to not issue any templates, get everything squared away with the new environment, AIA locations, CRL distribution, etc. Check health of all with the Enterprise PKI snap-in.

Then, when you're ready, alter the config of the existing CA to stop issuing certificates for certain templates. You aren't killing the server yet, just telling it to stop issuing new certs. Add those same templates to the allowed issuance policies of your new environment.

Then, use the "re-enroll certificate holders" option on the template management tool for the templates that have certificates out there and are auto-enrolled (user, computer, and domain controller certs). This will bump the template version and cause them to grab a new certificate from the new infrastructure when their autoenroll pulses.

This will cover you for those certs, but for web server certs it'll unfortunately be a manual process. Re-issue for each, and change listeners to the new certs.

Once you're fairly confident that you've got all the certificates re-issued, cripple the old CA but don't remove the role yet. Do something along the lines of removing all AIA or CRL distribution points in the CA's configuration, then deleting the files/objects from those locations (LDAP is probably the main one, but http and smb need checking too). Wait for issues for a few weeks; when something breaks, you can re-add the AIA/CRL points that you deleted and re-publish (certutil -dspublish) if needed.

Once you're satisfied that nothing's using the old CA anymore, remove the role, then clean up Active Directory. The AIA, CRLs, and delta CRLs need a manual delete, which you can do in the "Manage AD Containers" option in the Enterprise PKI snap-in.

  • Great answer, thank you--that will get me well on my way to making it happen. Also, I got some good news last night and found out that the old/existing CA server is slated to be decommissioned or repurposed in November, which should make the transition easier.
    – ewall
    Jun 3, 2011 at 13:23

According to this article: http://thedailyreviewer.com/server/view/multiple-enterprise-certificate-authorities-10276898 Microsoft does allow this but doesn't recomend it. We were faced with this choice we elected to offline the old server and start over. one of the first things we did was re-issue the certs on those actively using SSL.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .