travis' brain dump

So, a buddy of mine is working on a project where he needs to move his CA. I tried looking for the article that outlined the process I followed, but alas, I was unsuccessful. What does that mean!? It means I’m writing an article. 🙂

So, scenario… you’re rocking an old CA that someone installed on your local DC. For whatever reason, you don’t like this and need to move. Easy! (sort of) There’s a lot of different moving parts here and there’s a lot of assumptions I’m going to skip past here as the meat of the issue looking to be resolved is really just shifting the services from one CA to another. In my own experience, I typically will deploy an offline root CA and an online subordinate CA and maybe (depending on the size of the environment) other servers to handle different roles such as NDES, SCEP, etc. or maybe you want to change your naming convention up a bit and do something like pki.domain.com in your environment. However, we’re not covering any of that today, just the migration of CA requests from one CA to another. If you REALLY want me to write a post on any of the above, send me a note. My email is very similar to my site with just adding an @ in place of a ‘.’ … just sayin. 😉

Assumptions:

1. You’ve deployed a new CA or pair of CA’s into your environment.
2. The old CA is running on an old DC or old Server you want to get rid of.
3. You’re not doing anything crazy with your CA, just basic usage as I will not be covering identification of specific certificate template and version usage in this article.

USUAL DISCLAIMER: While these steps have worked for me, they may not work for you. I’m not responsible for you nuking your environment. 🙂 

Steps to complete the move:

1. Login to your old CA (as an Enterprise Administrator) and identify your AIA and CDP configuration. Just to make sure it doesn’t differ from standard.
   1. Open the Certification Authority Console
   2. Right Click the CA name and click ‘Properties’
   3. Click on the ‘Extensions’ Tab
   4. Document the distribution information for both your AIA and CDP portions. You can ignore the LDAP stuff, what you’re looking for looks similar to the following:
      1. CDP –
         http://<ServerDNSName>/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
         file://\\<ServerDNSName>\CertEnroll\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
      2. AIA –
         http://<ServerDNSName>/CertEnroll/<ServerDNSName>_<CaName><CertificateName>.crt
         file://\\<ServerDNSName>\CertEnroll\<ServerDNSName><CaName><CertificateName>.crt
2. Disable Delta CRL and Issue a long Revocation List (CRL)
   1. Open the Certificate Authority Console
   2. Right Click ‘Revoked Certificates’ and click ‘Properties’
   3. Uncheck ‘Publish Delta CRL’
   4. Change the value for “CRL Publication Interval” to 20+ years.
   5. Open a command line in admin mode and run ‘certutil -crl’ to issue the new list.
3. Copy the old CA cert and CRL list files to your new server.
   1. Navigate to Windows\System32\CertSrv\CertEnroll on the original CA
   2. Copy the Root Certificate crt file and the certificate revocation list crl file to the new server in the same location.
      (or whatever folder you chose to use for publishing your certificates via IIS on the new server) DO NOT RENAME THESE!
4. Redirect the AIA and CRL distribution points of the old CA to the new CA.
   You can accomplish this by doing a DNS name redirect (preferred) of the old CA to the new CA so that requests for http://oldserver.domain.com/CertEnroll/certificate.crt and certificate.crl are available. This is done so that the recorded CRL and AIA records in previously issued certificates are still valid so that when the CRL or validation is checked based on the certificate meta data, the url will still be available and valid. This is also why you DO NOT want to rename your old cert and crl from step 3. It *MUST* match entirely with the previously published information that you collected from step 1(4).
5. Document all used templates stored in AD and then remove them from the old CA to prevent any future publishing based on those templates.
   ALL templates must be disabled/removed. Once completed, the old CA will no longer be able to issue new certificates.
   1. Open an administrative command prompt on the old CA and execute ‘certutil -catemplates > c:\temp\catemplates.txt’ to get a full list of the templates.
   2. Launch the CA console on the old CA and navigate to ‘Certificate Templates’
   3. Make note of all leveraged certificate templates in this list.
   4. Highlight all of the templates in the list, right-click and select ‘delete’; this will not delete your templates from AD!
6. There may be a case here where you’ve got some oddities. In most cases, all of your certs should be good, but in some cases you may wish to issue specific certificates that didn’t fall into the default category immediately from the new CA. Review the certificate templates used to issue active certificates by taking a look at ‘Issued Certificates’ section and look for anything that doesn’t match up to the default certificate templates. This is an older link, but the list should still be valid. Default Certificate Templates In most cases, I don’t think you need to do this but every now and then you’ve got some oddity out there that’s worth at least being aware of. Auto-Enrolled certificates do not apply here even if you did some custom stuff.
7. Activate the leveraged CA Templates in the new CA.
   1. Login to the new CA and open the CA console as an Enterprise Administrator.
   2. Right-Click ‘Certificate Templates’, click ‘New’ then click ‘Certificate Template to Issue’
   3. Choose all the templates you documented in step 5(3) and click ‘OK’
8. Disable/Remove the CA role from the old system. You can do this step immediately upon testing that the new CA is issuing certificates or you can wait a few days. Since you removed the templates from the old CA you will not be issuing new certificates, but sometimes I like to leave it up for a few days to reference anything that may come up should I have missed something. In regard to the old CA cert and crl files, I usually will take a look at the latest expiration date of issued certificates on the old CA prior to decommissioning and record/set a reminder of when that date comes and goes so that I can clean up the old CA and crl files from within the new CA at that time. No sense in letting it hang around if you’re not using it. 🙂

I hope this helps someone out there to not be too scared of moving some CA roles around. There’s a couple different ways you can do this, but I found that this method worked best for me when I wanted to preserve the old CA (albeit not issuing) for a little while to track down anything strange that may pop up.