Jonathan Stephens posted an excellent Blog about this topic; however, it didn’t include the steps. As a result, I decided to type this Blog detailing the steps required. The following assumptions have to be met before proceeding with these steps:
1- There is a new valid Certification Authority configured
2- There is a new distribution point configured for AIA and CDP locations named http://crl.contoso.com/CertData
1- Logon to the old Enterprise Certification Authority as an Enterprise Administrator.
2- Identify the AIA and CDP distribution points
Note: Ignore the LDAP and C:\%windir% locations
3- Disable Delta CRL and Issue a long Certificate Revocation List (CRL)
4- Copy the old Certification Authority’s certificate (CRT) and certificate revocation list (CRL) files to the server hosting website http://crl.contoso.com/CertData
5- Redirect the Authority Information Access (AIA) and Certificate Revocation List (CRL) distribution points of the old Certification Authority to http://crl.contoso.com/certdata
6- Document and remove all certificate templates available on the old Certification Authority to prevent it from issuing new certificates
At this point, the old Certification Authority can’t issue any certificates, and has all of its Authority Information Access (AIA) and Certificate Revocation List (CRL) redirected to a new web site http://crl.contoso.com/CertData The next steps will detail how to document the certificates issued by templates from the old Certification Authority and how to make them available at the new Certification Authority.
7- Identify and document the certificates issued based on certificate templates by sorting the Certification Authority database
8- Dump the certificates based on the default certificate template types:
Note: Replace Template with the correct template name.
9- Dump the certificates based on the custom certificate template types:
Note: Replace OIDNumber with the number identified in step 9.e
Note: You don’t need to take any action if the certificate was auto-enrolled because the certificate holder will renew the certificate when it expires from the new CA infrastructure.
10- Enable the Certificate Templates needed based on the results of steps 7-9 on the new Certification Authority
11- <Optional> At this point you can uninstall the Certification Authority Role on the old Certification Authority
12- Once all certificates are issued by the new infrastructure, you can safely remove all the Authority Information Access (AIA) and Certificate Revocation List (CRL) files from you infrastructure by following the steps in How to Decommission a Windows Enterprise Certification Authority and How to Remove All Related Objects and from the web server hosting http://crl.contoso.com
Amer F. Kamal
Senior Premier Field Engineer
Hello Amer, Thanks for nice tutorial. I have question: in my domain I have offline root ca with subordinate enterprice ca. I must change root ca name, because someone dont like value "issued by". So is any way to change root ca name, renew certificate for subordinate ca and keep users certificates ? Thanks a lot for any solutions.
The name you are referring to is a CA Sanitized Name and can't be changed. The only solution for the issue you have is rebuilding the CA
Excellent guide! We're in the situation where our 5+ years old Win2003 DC has to be decommissioned since it's OLD and does not follow proper naming standards. However, it also has Enterprise Root CA installed and I'm investigating proper actions and I will suggest to do exactly what you've recommended above. But are there ANY arguments to instead setup a new 2008R2 CA standalone domain member and try to move the CA database to that server? Looking at the still active certs there's only Domain Controller certs issued.
One caveat though, there is one Subordinate CA issued to a CA in Spain. I guess if we start building a new CA structure, they will also need to build a new CA server in the new CA structure?
If I understand you correctly, you are suggesting to create an offline root CA and then importing the old Enterprise Root CA database. This is a bit complicated because you have to offline the CA. The easiest approach is following the steps mentioned in this blog and starting from scratch with a 2 tier hierarchy. If certificates were issued using autoenrollment, then they will renew from the new hierarchy without any issue. This should also apply to the CA in Spain.
Hope this helps!
I've found these 2 excellent guides and plan to use them at a new client.
The client currently has an enterprise root on a W2K3R2 DC that has issued many certificates based on only the standard templates. At somepoint an enterprise subordinate CA was also configured also on a W2K3R2 DC that has also issued many certificates based on only the standard templates. No custom templates are configured. The standard templates that have been used to issue certificates are:
No certs have been issued using the EFS recovery agent template (oops!)
Additionally, certs using a template CA Exchange have been issued.
The existing CA hierachy is barely functional because of old hardware and re/misconfiguration so I plan to simply replace it with a best-practice offline standalone root and subordinate enterprise CAs in a 2-tier hierachy based on W2K8 or W2K12 servers.
I've worked through the 2 articles and it's mostly clear except for a question I have regarding the versions of the pre-configured certificate templates. The W2K3 templates seem all to be version 1, and the latest templates can be version 3 or 4^, although most of the ones in use here seem to still be version 1.
My specific question concerns the steps exporting the "old" templates and importing them into the new CA. Assuming I have prevented creation of the standard templates on the new CA (LoadDefaultTemplates=false), do I have to do anything to avoid template version issues? Can I simply use the same-named templates from W2K12, do I use the "Compatibility" tab and duplicate, and lastly can I simply add the remaining new template types (that are not yet used)?
Your guidance would be appreciated.