Adding new root/enterprise CA without disturbing existing one?
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?)
Solution 1:
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.