Step-By-Step: Migrating The Active Directory Certificate Service From Windows Server 2008 R2 to 2019
Published Jun 18 2019 12:01 AM 332K Views
Microsoft

End of support for Windows Server 2008 R2 has been slated by Microsoft for January 14th 2020.  Said announcement increased interest in a previous post detailing steps on Active Directory Certificate Service migration from server versions older than 2008 R2.  Many subscribers of ITOpsTalk.com have reached out asking for an update of the steps to reflect Active Directory Certificate Service migration from 2008 R2 to 2016 / 2019 and of course our team is happy to oblige. This post contains steps on migrating the Active Directory Certificate Service to Windows Server 2019 that contains the same name. Check out this new post detailing steps on migrating the service to a newly named server should that be required.

 

Step 1: Backup Windows Server 2008 R2 certificate authority database and its configuration
 

  1. Log in to Windows 2008 R2 Server as member of local administrator group
  2. Go to Start > Administrative Tools > Certificate Authority
  3. Right Click on Server Node > All Tasks > Backup CA
     
    Certification Authority Backup CACertification Authority Backup CA
     
  4. Click Next on the Certification Authority Backup Wizard screen
  5. Click both check boxes to select both items to backup and provide the backup path for the file to be stored
     
    Certification Authority Backup Wizard Item SelectionCertification Authority Backup Wizard Item Selection
     
  6. Click Next
  7. Provide a password to protect private key and CA certificate file and click on next to continue
  8. Click Finish to complete the process

Step 2: Backup CA Registry Settings

 

  1. Click Start > Run > type regedit and click OK
  2. Expand the key in following path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc
  3. Right click on the Configuration key and click Export
  4. Provide a name, save the backup file and then click on save to complete the backup
     
    Backup CA Registry SettingsBackup CA Registry Settings

Backup of the Certificates is now complete and the files can now be moved to the new Windows 2016 / 2019 server.

 

CA Backup completeCA Backup complete

 

Step 3: Uninstall CA Service from Windows Server 2008 R2

 

  1. Navigate to Server Manager
  2. Click Remove Roles under Roles Summary to start the Remove Roles Wizard, and then click Next
     
    Uninstalling a CAUninstalling a CA

  3. Click to clear the Active Directory Certificate Services check box and click Next
     
    Removing Active Directory Certificate ServicesRemoving Active Directory Certificate Services
     
  4. Click Remove on the Confirm Removal Options page
  5. If Internet Information Services (IIS) is running and you are prompted to stop the service before you continue with the uninstall process, click OK
  6. Click Close
  7. Restart the server to complete the uninstall

Step 4: Install Windows Server 2016 / 2019 Certificate Services

 

*NOTE: The new 2016 / 2019 server needs to have the same "Name" as this point.  The screenshots below show the server name as WS2019 to highlight which server we are working on. This step-by-step highlights screenshots from Windows Server 2019. Windows Server 2016 process is the same with similar screenshots
 

  1. Log in to Windows Server 2019 as Domain Administrator or member of local administrator group
  2. Navigate to Server Manager > Add roles and features
  3. Click on next to continue in the Add Roles and features Wizard
  4. Select Role-based or Feature-based installation and click next
  5. Keep the default selection from the server selections window and click next
     
    Windows Server 2019 Server SelectionsWindows Server 2019 Server Selections
     
  6. Select Active Directory Certificate Services, click next in the pop up window to acknowledge the required features that need to be added, and click next to continue
     
    Adding Active Directory Certificate ServicesAdding Active Directory Certificate Services
     
  7. Click Next in the Features section to continue
  8. Review the brief description about AD CS and click next to continue
  9. Select Certificate Authority and Certification Authority Web Enrollment, click next in the pop up window to acknowledge the required features that need to be added, and click next to continue
     
    Windows Server 2019 Add Role ServicesWindows Server 2019 Add Role Services
     
  10. Review the brief description about IIS and click next to continue
  11. Leave the default and click next to continue
  12. Click Install to begin the installation process
  13. Close the wizard once it is complete

 

Step 5: Configure AD CS

 

In this step will look in to configuration and restoring the backup created previously

 

  1. Navigate to Server Manager > AD CS
  2. In right hand panel it will show message as following screenshot and click on More
     
    AD CSAD CS
     
  3. Click on Configure Active Directory Certificate Service …… in the pop up window
     
    Configure Active Directory Certificate ServiceConfigure Active Directory Certificate Service
     
  4. In the Role Configuration wizard, ensure the proper credential for Enterprise Administrator is shown and click next to continue
  5. Select Certification Authority and Certification Authority Web Enrollment and click next to continue
  6. Ensure Enterprise CA is selected the setup type and click next to continue
  7. Select Root CA as the CA type and click next to continue
  8. With this being a migration, select Use existing private key and Select a certificate and use its associated private key and click next to continue
     
    AD CS ConfigurationAD CS Configuration
     
  9. Click Import in the AD CS Configuration window
  10. Select the key backed up during the backup process from windows 2008 R2 server. Browse and select the key from the backup we made and provide the password we used for protection and click OK.
     
    Import Existing CertificateImport Existing Certificate
     
  11. With the key successfully imported and select the imported certificate and click next to continue
  12. Leave the default certificate database path and click next to continue
  13. Click on configure to proceed with the configuration process
  14. Close the configuration Wizard once complete

 

Step 6: Restore CA Backup

 

  1. Navigate to Server Manager > Tools > Certification Authority
  2. Right click on server node > All Tasks > Restore CA
  3. A window will appear confirming the stop of Active Directory Certificate Services. Click OK to continue.
     
    Confirm stop of Active Directory Certificate ServicesConfirm stop of Active Directory Certificate Services
  4. Click Next to start the Certification Authority Restore Wizard
  5. Click both check boxes to select both items to restore and provide the backup path for the file to be restored from
     
    Certification Authority Restore WizardCertification Authority Restore Wizard
  6. Enter the password used to protect private key during the backup process and click next
  7. Click Finish to complete the restore process
  8. Click Yes to restart Active Directory Certificate Services

 

Step 7: Restore Registry info

 

  1. Navigate to the folder with the backed up registry key and double click > Run to initialize the restore
  2. Click yes to proceed with registry key restore
  3. Click OK once confirmation about the restore is shared

 

Step 8: Reissue Certificate Templates

 

It is now time to reissue the certificate with the migration process now complete.

 

  1. Under Server Manager, navigate to Tools > Certification Authority
  2. Right click on Certificate Templates Folder > New > Certificate Template to Reissue
  3. From the certificate templates list click on the appropriate certificate template and click OK

 

This concludes the Active Directory Certificate Service migration steps

 

The following video also shares steps surrounding this process as well as migrating DNS.

 

109 Comments
Copper Contributor

@Paul_Adare   

My environment is exactly the same as @Dean Chen  all running on 2008R2. I'm also against in place upgrades if they can be avoided. So this thread initially had me concerned I was going to have to in place upgrade to 2012R2. 

From your clarification, it sounds like I just build 3 new 2019 servers, install ADCS, export the configurations out of my 2008R2 servers and then import it into my 2019 servers. Done!  

Sound right? You mentioned this is well documented and tested. Yet we are all on this thread in this MS blog, because there is a serious lack of official MS documentation on this. I miss the old days when MS provided great technical docs on everything. Now it seems, you have to rely on the community and their experiences. 

Thanks

Microsoft

@GGearon The documentation I was referring to is in regards to performing a migration. The only documentation about needing to go to 2012 R2 as an interim step is documented in the Wiki and specifically refers to 2008 and not to 2008 R2 - https://social.technet.microsoft.com/wiki/contents/articles/37373.migrating-ad-certificate-services-...

 

There are loads of articles regarding migration in general, nothing really specific to 2019 but the process is exactly the same.

 

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn...

Copper Contributor

@Paul_AdareThanks so much for your comments in this post and confirming the current Microsoft Windows 2012 R2 CA migration document works for Windows 2016/2019 CA migration as well. This clears a few doubts in my mind. :=)  It would be nice to have an official Microsoft document that could combine Windows 2012 R2 CA migration document and this post for Windows 2016/2019. It took me for a while to search answers until I found this post. Not sure how many others are still scratching their heads. :=)

 

@GGearonMy thought is that with this post as the guideline for Windows 2016/2019 CA, we just need to follow the steps in Windows 2012 R2 CA migration document that Paul shared. that should be it. Good luck!

 

@Anthony BartoloThanks for posting this document here too!

 

Thanks,

Dean

Copper Contributor

Just wanted to say thank you for making this step by step guide available.  I migrated my Server 2008 32 bit Enterprise Root CA to Windows Server 2019 with out any issues.  Just wanted to say thanks for making this documentation available.

Copper Contributor

@Anthony Bartolo Did you ever manage to create an article for migrating to a server with a different name?

Copper Contributor

@Paul_Adare I'm glad I read through all the comments to see your contribution. Kinda makes a big difference to - we have too much 2008r2 migration activity going on to be dealing with pointless doubling of ADCS migration efforts, so I thank you very much.

 

Now, you referenced https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn...) and from reading through (as best as a guy with ADHD is able), I don't see reference to using a different destination server name. 

 

This older article does https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee.... See the dirty yellow text box. However, it's an earlier articles by a few years. I'm thinking it IS still possible to have a different Server name (not changing the CA name) using the same procedures, but it would be nice to have that clarified on here and also factored into MS publications.

Copper Contributor

Hello. Is this the same for any subordinate CAs? And should the subordinates be done after the root CA?

 

Thanks for your Article.

Copper Contributor

@Paul_Adare 

Thank-you for confirming the process, the interwebs has so much miss-information now, everyone is an expert and sifting through can be a challenge sometimes.

 

We have an offline CA and to issuing Sub-CA's, plan is to go from 2008 R2 to 2019 like everyone else.

would we do the Root CA first then do each of the issuing Sub-CA's one at a time?

Assuming the process is the same for the Sub-CA's??

Microsoft

@RedLimey it has always been possible to migrate to a server with a different host name, it is just more complicated. If you use the same host name, you can export all of the registry configuration from the old server and import it into the new server with no modifications. If you use a different host name, you need to ensure that you've changed a relevant entries and things can be missed that way.

Microsoft

@Dave_Hanna the process is the same and the order is irrelevant.

Microsoft

@VictorLQ the process is the same and the order is irrelevant.

Copper Contributor

@Paul_Adare I inherited an ADCS that was installed on our primary DC and has since been migrated as upgrades from 2003 to now 2016 occurred but still remains on the DC. I want to move this off to a root ca and a sub ca. The server names will not be the same. Is there a good guide for this? Pitfalls to look out for? Anything?

Copper Contributor

I should say. Full replacement of the existing ADCS is an option and likely the path we’d want to go as the old ADCS is still at sha1.

Microsoft

@Rcdonovan If it were me, I'd plan on building net new from scratch. Once you've got your new PKI deployed, remove any templates from the old CA but leave it running so that it can continue to publish CRLs. Once all the certificates it has issued are no longer time valid, remove the role service.

Copper Contributor

Thanks @Paul_Adare 

Copper Contributor

@Paul_Adare So just to be clear, rename the 2016 server to the old server name before starting the install/restore process?

Microsoft

@jasonmeyer Correct, and join it to the domain.

Copper Contributor

@Paul_Adare 

Thank you for stepping in here...  Like many others I have a 2008R2 CA and am looking to go to a 2019 Server. 

Current CA is working, though I installed it back in 2006 to Support SCEP for Cisco VPN, which is no longer used. 

 

Though Since I have installed the CA, the Domain PCs, Servers, DCs and some users have been issued Certificates from the 2008R2 CA. I'm not Specifically using them for anything. The CA was installed on an Old DC and we have not demoted the DC it because of the CA.    I'm fine with a Completely new 2019 Server with a new CA. The old CA and old CA Host name are the same and I would love to change them Both. 

 

I was thinking of:

  • Setup a new 2019, set it as the default new Enterprise CA,
  • Add Old CA's public cert to the new Enterprise CA Trusted List of CAs.
  • Configure the new Enterprise CA with CRL,
  • Reconfigure GPO to submit Requests to the new Enterprise CA.
  • Renew certs against new Enterprise CA
  • Wait for old Certs to Expire/Force Machines/Users to renew.
  • Remove old 2008R2 CA Server
Copper Contributor

@Paul_Adare 

appreciate all your input, can you please clarify one thing for me, we have a 2008 r2 CA and looking to migrate to 2016, if we decide to build a new 2016 server with a different netbios name but keep the CA name, when we uninstall the CA role from the 2008 r2 server can we keep this server running? as its a DC and we need tor DNS temporarily?

 

Appreciated.

Microsoft

@MS-Usy786 Yes, of course you can keep the DC running. Keep in mind that the migration will be more complex when changing the host name. My suggestion would be to stand up a new DC, install the DNS role on it, and then remove the old DC completely, then use the old DC's host name for the new CA.

Copper Contributor

@Paul_Adare thanks Paul, appreciated, our DC is called DC1  but the CA is called XXXCA, the new DC is Called DC2 but the CA will be the same name. to clear up any confusion, the CA name will remain the same but the netbios name will change? does that pose complexity also? thank you in advance.

Microsoft

@MS-Usy786 A couple of things here, yes, I was referring to maintaining the original host/NetBIOS name for your new CA. That makes the migration less complicated. It obviously isn't a hard requirement, just a strong recommendation. Am I understanding correctly that you're installing the new CA on a DC again? If so, that is a really bad practice and one that I strongly urge you to reconsider.

Copper Contributor

@Paul_Adare thanks for the heads up, we are going to remove CA from original server, install CA on a member server (non-DC) and remove the old server from the domain. Rename the new server to the netbios name of the original CA and restore database etc... 

Thanks again for the advice.

Copper Contributor

@Paul_Adare one last question please Paul, we are using SHA1 and our current provider is the legacy MS Strong Crypto provider, is there any issues still migrating to 2016? and then after, maybe a month or so upgrade to SHA2? is it a painless process? or quite difficult? as we have lots of certs out there. Thanks in advance.

Microsoft
Copper Contributor

@Paul_Adare Like the rest of us here I'm in the same boat. Your comments helped me a lot so far. Just want to know more about why it's not a good idea to install CA on a DC? I have multiple clients working like this without any trouble. Or is it because it could make the server too complicated or complex to ever migrate again?

Can you please clarify? Thanks!

Microsoft

There are a couple of main reasons why this is not recommended:

  1. As with any critical infrastructure server, the attack surface should be minimized. This means dedicated, purpose built servers. The steps you need to take to secure and lock down a domain controller may not be compatible with those for a CA and vice versa.
  2. The recommended approach to "upgrading" domain controllers is to build new and retire the old. That is not possible when your DCs are also CAs as you cannot run dcpromo to demote a DC when it is also running ADCS.

 

Copper Contributor

@Paul_Adare Thanks for your quick response Paul. The first reason makes absolute sense regarding security. The second one is more about how much work you're willing to put yourself through in the future, so more or less debatable.

Thanks again!

Copper Contributor

hi @Anthony Bartolo @Paul_Adare Thanks for your effort on this topic.

Do you have instruction of how to Migrate CA from 2008R2 or 2012R2 to 2016 with different hostname?

Copper Contributor
Copper Contributor

@Paul_Adare I appreciate reading your responses.

 

With my 2008R2 CA, it is indeed installed on a DC (Which I see now is a bad practice)

 

I have spun up a new Server 2019 and want to move my CA to this. Ideally I wanted a new host name.

 

Can I have this 2019 be a second CA for my domain and migrate over to it?

Copper Contributor

Many Thanks for the Contributers to the comments on this article.

@Paul_Adare (or one of the many knowledgable contrubutors)

My query is again regariing migrating to a new Hostname.

I have read, here, that is both simple and complicated.

My understanding is that is simpy (!) a case of performing a search and replace on the exported registry file from the source server, replacing the old hostname, with the new hostname, before importing on the detination server.

Am I missing something?

 

NB I have scoured both the 2012 and 2016 versions of the migration white paper and I can't see where it addresses differences in procedure for a host name change, no mention of modifying the .reg file , for instance. The references mention that it can be done,

Thanks again.

Keith

Copper Contributor

@Anthony Bartolo  Thanks for the post. @Paul_Adare  thanks for the additional comments. It is nice to see that there are fresh replies to the comments for us "late upgraders" :)

 

I still need to embark on upgrading our offline root CA and single subordinate CA from 2008r2 and need to do this soon. I have a couple of questions if you are able to answer them?

 

1) Will there be any downtime associated with performing this migration? The CRL will be down while we perform the upgrade.

2) We are thinking about adding additional availability to our CA infrastructure. Should we do this at the same time?

3) Is it recommended to separate the AIA and CDP locations away from the issuing servers? Can we also do this as part of this process (if necessary).

 

I think i am adding too much complexity to this process and just need to concentrate on getting the migration done first.

 

Regards,

 

Mark

Microsoft

@MCroom If you plan it correctly, your downtime should be minimal. If you're hosting the CDP and AIA locations on the online CA(s), that is a bad practice. Given the high asset value assigned to CAs, you really should not be running IIS on them. You want to minimize the attack surface. I don't know what the lifetimes of your CRLs are but one solution during the migration is to host the certs and CRLs on another server running IIS and use DNS to redirect the current URL to this new server.

I assume by wanting to add additional availability you're talking about adding CA(s) that have the same templates published? If so, then I'd probably do the migration first, then after things have settled down and you're sure things are working correctly, add the new CA(s).

For your 3rd question, yes, this is a best practice. You can change the CDP and AIA URLs by editing the registry (don't forget the root CA) but keep in mind that any existing time valid certificates will still contain the old URLs so you need to handle that to prevent outages.

Copper Contributor

So I'm currently working on my upgrade from 2008R2 to 2019 servers, in a lab. My environment is as follows.
Standalone Root CA

Enterprise Issuing CA

Enterprise OSCP Responder/CRL holder

 

I basically followed this article step by step to build a new root ca on 2019. Kept the same name all that. Seemed to go fine.

 

Then I followed this article step by step building a new issuing ca on 2019, keeping the same name etc. Went all fine until the end when I did the restore. At the end, it said could not start the ADCS service because of the RPC was not running and could not verify CRLs. From there I rebooted, and launched CA console. The templates showing as issued were the generic versions, not my customized ones. When I try to issue the correct one, I get the same errors. 

 

To move forward with my migration, do I maybe need to build the OCSP Responder/CRL holder server first, before the issuing ca? That way it will see the CRL and be happy? Also, for the OCSP Responder, I assume I just follow this document step by step, but add the role features to go with that? 

 

Thanks

Copper Contributor

My migration is complete. In case it helps anyone going through this here are some items I came across and did. 

 

I kept the same exact server names across the board. 

I migrated the root CA first which being a stand alone was no biggie. 

I then did my OCSP responder second. For my environment, before configuring the Online Responder I created a virtual directory in IIS pointing to where I keep the CRL files. My experience was if I didn't do this first, the Online Responder configuration would not work otherwise. 

Third I did my Issuing CA. I followed the documentation provided in this thread. I did run into this situation in my lab and in prod....

When I went to issue the templates, none of my configured/duplicated templates showed up in the list of templates on this CA. Here is the fix for that. 

Go into a domain controller, open adsiedit.msc  Open initial connection, right click on default naming context and properties. Choose the drop for configuration. 

Open CN Configuration>CN Services>CN Public Key Services>click on CN Enrollment Services. 

On right pane, select and right click on CN="your issuing ca name" and choose properties. 

Scroll down to "flags" setting. If it is set to 2, edit this and set it to 10. This indicates to AD that this is an Enterprise CA. 

Wait a few minutes for that change to propagate through AD, then a new session of CA management console on your new issuing CA. 

Brass Contributor

@Paul_Adare@Anthony Bartolo  Hello! Thank you for all of this information! We are interested in setting up a fresh new PKI on the same domain since the current one has all of the PKI roles on a single server. Is there an official guide/site that shows how to set up a parallel PKI on the same domain without causing any problems?

 

What is the current best practice for what PKI roles to separate, and how many servers to use?

 

Thanks!

Copper Contributor

Hello @Paul_Adare@Anthony Bartolo - Same question as AakashShah, try to  move from my current PKI from a single one tier hierarchy to a Two Tier Hierarchy

 
Copper Contributor

One of the best step-by-step guides I ever encountered.

Works for 2012R2 target also.

Copper Contributor

@Paul_Adare I am very late to this party and hoping you are still around.  I inherited a 2008 R2 server with ADCS installed.  I'm trying to demote this server from AD services and eventually completely remove it, but discovered ADCS was installed.  This was done before me but I'm not sure we are even using it.  Picture below.  Any articles or information on how to dismantle an ADCS?

CAServices.PNG

Copper Contributor

Anthony Bartolo   - was there a follow up to restore the CA onto a new server with a different name?

 

my source is a win 2008 R2 enterprise, which is also a domain controller and I want to move the CA to another server 2012 or 2016 is possible with a new name (member server).

 

was there a follow up to the original post?  i don't the option of shutting down the DC just yet., thanks for your help.   Wil

 
Copper Contributor

Hi @Paul_Adare@Anthony Bartolo

I have a 2012 DC with a CA installed. I was hoping to move the CA off the old DC server to a 2012r2 member Server with a different NETBIOS name. I read on Spiceworks where several have completed this importing the reg file from the old server keeping the CA name the same. Any help appreciated. Thanks!

Copper Contributor

Thank you for this! @Anthony Bartolo 

Is the process the same if you have an Offline Root CA and 2 subordinate CA's migrating from on-prem to Azure IaaS? Should I start with the Offline Root CA first and then the 2 subordinate CA's (one at a time)? Thanks in advance!

Copper Contributor

I am successfully able to migrate 2 tier certification authority. Everything is fine but seeing "CA Certificate" as unknown for both Sub-CAs. CRL update went fine after migration, cert enrollment is also fine. 
Please help if some had the same kind of scenario.

@Anthony Bartolo 

Copper Contributor

@Paul_AdareHi ,

is there any steps need to be done if in my scenario i need my win2008 32bit CA decommissioned completely ?

beside removing the ADCS Role ?

Thanks in advance

 

Copper Contributor

Hello, Please advise backward compatibility of migration from 2016 to 2012 R2, I am getting error message while restoring the CA database, hence please confirm whether backward compatibility is possible ? kindly help me.  

Copper Contributor

Hi,

 

there is one part of this migration process which I do not quite understand. What happens to the custom templates after uninstall of the CA Role? Do we need to re-create them or is it possible to recover them? Thanks

Copper Contributor

Custom templates are stored in the Configuration container of Active Directory - not the CA. So when you uninstall the CA, they are preserved in AD. When you need to add them to a new CA or a migrated CA, you can select them from the list of all available templates in AD.

Copper Contributor

@Thepkiguy 

 

Thanks for your quick reply. This will make the process easier than I thought.

Copper Contributor

If anyone wants to see a more complete version of the steps, including exporting the list of published templates on the legacy server and copying CAPolicy.inf if required, then the old PFE blog on how to migrate is still the easiest and most complete guide to follow: 

Upgrading Your PKI from Windows Server 2003 to Windows Server 2008 R2 Part IV: Migrating Enterprise ...

 

I don't know why this article and the MS Learn version weren't simply updated  and expanded from that, since the basic steps are exactly the same. The MS Learn article includes some more detail and troubleshooting advice, but the layout is a little confusing - someone might not realise that there are different steps between recovery to a server with the same name and a server with a new name given in that document (naturally, the second option is not preferred).

Co-Authors
Version history
Last update:
‎Jul 09 2021 12:30 PM
Updated by: