Decommissioning an Old Certification Authority without affecting Previously Issued Certificates and then Switching Operations to a New One


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

Steps:

1- Logon to the old Enterprise Certification Authority as an Enterprise Administrator.

2- Identify the AIA and CDP distribution points

  1. a. Open the Certification Authority Console
  2. b. Right click the Certification Authority name and click Properties
  3. c. Click the “Extensions” tab
  4. d. Document the distribution points configured for CRL Distribution Point (CDP) – as an example http://<serverDNSnname>/CertEnroll/<CANAME>CRLNameSuffix><DeltaCRLAllowed>.crl which refers to local IIS installed on the server, or http://pki.contoso.com/Certenroll/<CAName><CRLNameSuffix><DeltaCRLAllowed>.crl

Note: Ignore the LDAP and C:\%windir% locations

  1. e. In the “Extensions” tab, select Authority Information Access (AIA) from the drop down menu
  2. f.  Document the distribution points configured for the AIA extensions – as an example http://<ServerDNSName>/Certenroll/<ServerDNSName>_<CAName><CertificateName>.crt  which refers to the local IIS installed on the server or http://pki.contoso.com/Certenroll/<ServerDNSName>_<CAName><CertificateName>.crt

Note: Ignore the LDAP and C:\%windir% locations

3- Disable Delta CRL and Issue a long Certificate Revocation List (CRL)

  1. a. Open the Certification Authority Console
  2. b. Right click “Revoked Certificates”, and then click “Properties”
  3. c. Uncheck “Publish Delta CRL”
  4. d. Change the “CRL publication Interval” to 99 years and then click OK
  5. e. Open the command line with elevated privileges
  6. f.  Run Certutil –crl  to issue a new 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 

  1. a. On the old Certification Authority, navigate to %windir%\System32\CertSrv\CertEnroll
  2. b. Copy the Certification Authority’s certificate (CRT) and certificate revocation list (CRL) to the directory hosting 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

  1. a. This can be done using an IIS redirect, or a DNS CNAME redirect to redirect Authority information Access (AIA) and Certificate Revocation List (CRL) of the old Certification Authority documented in steps 2.d and 2.f to the new web server 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

  1. a. Open the command line with elevated privileges
  2. b. Run Certutil –catemplates > c:\catemplates.txt  to document all available certificate templates at the old Certification Authority
  3. c. Launch the Certification Authority console
  4. d. Navigate to “Certificate Templates”
  5. e. Highlight all templates in the right pane, right click and then click “Delete”

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

  1. a. Highlight “Issued Certificates”
  2. b. Navigate to the right, and sort by “Certificate Templates”
  3. c. Identify the certificates issued by default certificate template types
  4. d. Identify the certificates issued by custom certificate templates – any template other than the default certificate templates mentioned earlier

8- Dump the certificates based on the default certificate template types:

  1. a. Open the command line with elevated privileges
  2. b. Run Certutil -view -restrict “Certificate Template=Template” -out “SerialNumber,NotAfter,DistinguishedName,CommonName” > c:\TemplateType.txt
  3. c. Examine the output of c:\TemplateType.txt and document all the certificates needing immediate action – i.e. requiring issuance from the new CA infrastructure if needed such as Web SSL.
  4. d. Consult with the application administrator using the certificates to determine the best approach to replace the certificates if needed

Note: Replace Template with the correct template name.

9- Dump the certificates based on the custom certificate template types:

  1. a. Open the Certification Authority Console
  2. b. Right click “Certificate Templates” and click “Manage”
  3. c. Double click the certificate template and click on “Extensions” tab
  4. d. Click on “Certificate Template Information”
  5. e. Copy the Object Identifier (OID) number – the number will look similar to 1.3.6.1.4.1.311.21.8.12531710.13924440.6111642.16676639.10714343.69.16212521.10022553
  6. f. Open the command line with elevated privileges
  7. g. Run Certutil -view -restrict “Certificate Template=OIDNumber” -out “SerialNumber,NotAfter,DistinguishedName,CommonName” > c:\CustomTemplateType.txt

Note: Replace OIDNumber with the number identified in step 9.e

  1. h. Examine the output of c:\CustomTemplateType.txt and document all the certificates needing immediate action – i.e. requiring issuance from the new CA infrastructure if needed such as custom SSL certificates.
  2. i. Consult with the application administrator using the certificates to determine the best approach to replace the certificates if needed

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

  1. a. Logon to the new Certification Authority as an Enterprise Administrator
  2. b. Right Click “Certificate Templates”, click “New” and then click “Certificate Template to Issue”
  3. c. Choose all the certificate templates needed in the “Enable Certificate Templates” window and click “OK”

11- <Optional> At this point you can uninstall the Certification Authority Role on the old Certification Authority

  1. a. Backup the old Certification Authority using the steps outlined in Disaster Recovery Procedures for Active Directory Certificate Services (ADCS)
  2. b. Uninstall Certificate Services from the old Certification Authority
  3. c. Decommission the server unless it is running other applications

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

Comments (38)

  1. Amerk [MSFT] says:

    Martin.

    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

  2. Amerk [MSFT] says:

    Hi Matthias, It can be the new distribution point of the new CA, or a separate distribution point hosted on another web server. Best practice for CA distribution points calls for creating a separate web site hosted on a non-CA server. You need to copy
    the CRL and AIA files from the old CA to the distribution point, regardless of the distribution point selected above.

  3. Amerk [MSFT] says:

    James,

    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!

  4. Amerk [MSFT] says:

    Hi TuanBA.

    If you lost the Root CA, then you have to build from scratch. I am assuming a lost CA means you can’t locate backups/Private Keys etc…

  5. Anonymous says:

    Some great pointers However I need to migrate Both my offline Root as well as my Issuing CA from 2008R2 to 2012 Servers plateform, I need some advice on what’s required .

    1. Hi Anonymous,
      could you please let us know your specific questions? Did you already take a look at https://technet.microsoft.com/en-us/library/ee126170(v=ws.10).aspx

  6. Martin says:

    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.

  7. james says:

    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?

  8. Richard says:

    Hello Amerk,

    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:

    Administrator

    Domain Controller

    Basic EFS

    Computer

    User

    Subordinate CA

    Web Server

    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.

    Richard

    Switzerland

  9. matthias says:

    Hi Amerk, I hope you still reading this 🙂 First, thank you for the guide. But I have one littel thing wich is confusing me and it is right at the beginning. 2- There is a new distribution point configured for AIA and CDP locations named http://crl.contoso.com/CertData
    About the new distribution point. Do you mean the new distribution Point of the new CA or do mean a separate distribution Point where I have to put the old CRLs and CRTs? Sorry for that stupid question 🙂 Thanks in advance Matthias

  10. Raf Smets says:

    Hello All, a very good blog, appreciated.
    I have a question about auto-enrolled certificates. When the the auto-enrolled certificates get renewed against the new active CA, do they renew keeping their original public and private key-pair. Also does the certificate subject key identifier change after the renewal process?
    Regards
    Raf

  11. TuanBA says:

    Thanks for your good guide. If I lost root CA, can I do step by step with your guide?

  12. TuanBA says:

    Hi Amerk,
    My Root CA server was turned off and moved store without backup. now, I can’t find RootCA server. Maybe, this server was taken away for other goal. Pleas help me detail without causing an interruption in my business. Thank you very much!

  13. TuanBA says:

    Hi Amerk. I have already buit new PKI. And I did the steps in your blog. Everything have run smoothly.
    Thank you so much!

  14. Hernan says:

    Excellent guide!, thanks for posting. I got a question that has nothing to do with this post, but i can’t find it anywhere.
    We have and old Standard Root Certification Authorithy running on W2k3, but we are trying to start using customized templates, so we have to deploy an Enterprise CA, is there any change that i would deploy a new Enterprise "Subordinate" CA on W2008R2 but keeping
    the Old standard root CA on w2k3 in order to minimize the heavy task of a brand new hierarchy ? this would enable us the ability to use custom templates?
    Thanks for your time!
    regards

  15. paul says:

    Hi Amerk,

    I just came across your great blog and I was a little too late finding it  as I did the CA migration already from 2003 to 2008. I followed the following guide but it was not as detailed as yours 

    http://blogs.technet.com/b/meamcs/archive/2012/03/27/migrating-windows-2003-enterprise-certificate-authority-to-windows-2008-r2-based-ca.aspx

    So this where I stand now; the new 2008 AD/CA server has a different host name than the old CA server name and after I did the migration to the new 2008 CA host name it took the name of the old server host name and would like to know if there is a way to change
    this or if I just leave it as is would it cause issues?

    The new CA server name seems functional as far as I can tell. Do I need to perform steps listed in your great guide? Should I restore/revert to the old CA server and start over with your guide, is this possible?

    I have 4 certs that are “Subordinate Certification Authority (SubCA) and just want to make sure they are being issued from the new CA server. How do I determine that?

    P.S New 2008 CA server is an Enterprise CA.

    Thank you

  16. Gary says:

    I have a Windows 2008 Enterprise CA and need to move it to a 2012 R2 server with a different host name than the 2008 box. This article references a PKI but I’d like to know if this is recommended for a CA to CA with a different host name. My fear is that
    vpn, wireless, and other machines that have existing certificates will be affected as the previous article suggested. Any confirmation how to proceed would be awesome. I’m confused now a bit. Thanks.

  17. MMuellenbach says:

    Thanks for this guide, Amerk!

    Perhaps you can help me in with a problem I am facing right now.
    Acutaly I am in the process of renewing a local PKI, because the old PKI is installed on old servers with a SHA1 key.

    We would like to set up a new PKI on new machines with new keys. This means, we would have two Enterprise PKI at the same time within our AD Domain.

    Our clients authenticate against our WiFi using machine certificates via a radius server. So far so good.

    Do we have to set up a new radius server, or will the old one be able to trust both certificate authorities and authenticate our clients against the old and the new CA at the same time?

    We would like to stop the autoenrollment on the old CA and enable it on the new one, and within 90 days, the old certificates will not be valid anymore. 90 days is the configured validity period for our computer certificates.

    After 90 days, we would remove the old CA.

    Is this a valid scenario?

    Thanks for your help in advance!

  18. Rashid Amin says:

    Amer,
    We have a CA in our hosted exchange domain. Other than what is automatically issued, we don’t have any special certificates being requested or issued. The issued certs seems to all be domain controller and web server certs that we never really asked to be issued.
    At this point, we want to move off the current server to the new server. Do we still have to go through migrating it or can we just uninstall it and then install a new CA in the domain. Do we absolutely need a CA in the domain?

  19. Jamey says:

    Amerk,

    Can you please explain with an example how to redirect using either IIS or DNS in step 5. I can’t figure out exactly how to do this – thanks in advance.

  20. WafflesMcDuff says:

    We currently have an Enterprise CA running on Server 2008 R2 that was migrated from 2003, so it is a CSP. Would I be able to follow these steps if I want to commission a new Enterprise CA (KSP) and transfer all CA functionality to the new KSP, with the
    ability to issue SHA256 certs etc?

  21. lucy says:

    great post from your hands again. I loved the complete article. By the way nice writing style you have. I never felt like boring while reading this article. I will come back & read all your posts soon. Regards, Lucy.

  22. James Wilson says:

    Hi Amer, thank you for the guide. I am looking to decommission an our old WK2003 root CA and create a new 2012 root CA, I am not looking to migrate the database across as I want to change the server name but I was under the impression you had to demission
    the old one first, but I guess that’s not the case? So do I just create a new root CA then follow your guide to decommission the old one and switch to the new one?

  23. Anonymous says:

    In a scenario where the Domain Controller template through which certs were issued on all DCs is disabled on the old enterprise root CA (single tier PKI) and enabled on the new subordinate issuing CA (parallel 2 tier pki), will the DCs get the new certs through the Domain Controller template only after the old certificate expires? if yes and we don’t want to wait till the cert for all DCs expire, do we have to revoke the cert on the DC or delete it from the personal store? In this case, we don’t want to use any of the v2 templates on the new CA.

  24. joe squirrel says:

    We upgraded our CA from Windows 2003 quite some ago and everything has been functioning normally but just now we need to create new server/client certificates and are unable to do so. Templates are not available. We have searched for a resolution for this and have verified some of the answers with no results. It looks as though we will have to rebuild or better yet create a new CA (server 2012 preferably). Does anyone have a procedure on completing this as we need these certificates.

  25. Nenad Muzic says:

    Hi, excellent guide! Can I use it as an approach where 2 PKI exist in parallel?

  26. JR says:

    Trying to understand if these steps are absolutely NEEDED if I am migrating my CA from one server to another server that has a different computername. (or if they’re only needed in certain situations?). Please advise.

  27. Thanks for this! In your scenario, how do member computers,that trusted the old CA chain, trust the new CA chain? Wouldn’t you need to use a GPO to deploy the Root CA and Sub CA as Trusted to the member computers? Or is that step handled auto-magically by deploying an AD integrated CA? Thanks again!

  28. Jesse says:

    Hello, are these steps absolutely REQUIRED when I migrate the CA services from Server A to Server B, where the computer-name itself CHANGES? (From what I read, I can still migrate CA services to a server with a new computername, but the CA-name itself still needs to be the same when installing the CA services).

    1. WesH [MSFT] says:

      Leaving the computer name the same allows for the ACL’s on objects in the directory to continue to be used. If you change the name you still need to maintain the old CRL locations in LDAP if you leveraged it and they are in a container with the Old CA Hosts name.

  29. Colin says:

    Hi Amer, firstly thanks for this guide, its very useful.

    Prior to seeing this guide i had built a two tier PKI on Windows Server 2016 consisting of one offline standalone Root CA and One Enterprise issuing CA.

    I have some question regarding section 4. As i have an offline Root CA i have configured custom AIA and CDP locations using a DNS Alias which uses an http location on the issuing/subordinate CA.

    So question is, should the old CRT and CRL files from the legacy CA be copies there?

    Appreciate of you can clarify, many thanks.

    1. WesH [MSFT] says:

      Hello Colin, sorry for the delay….Yes, they should be kept and placed in the new location so signature and CRL checks can continue for certificates that are still out there.

  30. Hi Amer,
    thanks for this awesome article. It clarifies a number of the specific steps in this process.
    Do you have any advice for dealing with non Auto-Enrolled certificates (such as certificates issued to NPS and/or Cisco ACS for use in PEAP authentication, or certificates enrolled to non-Domain joined devices)?

    I have a legacy PKI (2-tier) that is trusted by many legacy devices in a particular division involving lots of mobile & roaming devices, and a new 3-tier enterprise PKI that supports the whole organisation. I know I can relegate the old CA so that no new certificates are issued, but we have a large legacy of devices that are enrolled in the OLD PKI,

    For instance, can I have the new DivisionA SubCA “cross-signed” by the old root CA?
    So that all new devices (and re-configured devices) trust the new PKI, and old (legacy/not-yet configured) devices can use the new PKI because it is trusted (signed) by the old Root-CA?

    We have several hundred sites using the old CA, and many thousands of BYO & non-managed devices that trust the old Root CA. The process of installing the new CA certificate into the trusted certificates store of these devices will take many, many months.

    As these certificates are used for 802.1x authentication, and the NPS/ACS authenitcation servers need to be upgraded on the New PKI, finding a solution for this is quite important for us.

    Thanks for any assistance/advice you can offer. (I am hoping I am overlooking an simple solution – because qualified subordiation looks overly complicated for this task)

    1. Hi Crispin,
      regarding cross-signing CA certs you might want to take a look at certeq -policy to create a new certificate request for an existing CA certificate. You could then submit this request to another CA and issue a new CA certificate signed by that CA.
      Here is some info regarding the syntax of the policy.inf: https://blogs.technet.microsoft.com/pki/2014/03/05/constraints-what-they-are-and-how-theyre-used/
      You can find more regarding cross certification here: https://blogs.technet.microsoft.com/pki/2010/05/12/certificate-path-validation-in-bridge-ca-and-cross-certification-environments/

  31. Harry says:

    Hi Amerk,

    We need to migrate Enterprise CA from a Domain Controller (2003 R2 x64) to a new DC (2008 Sp2 x64). Both DC’s have different host names, can i still migrate and how do i maintain same CA name (I read its required). Thanks

    1. WesH [MSFT] says:

      It is not required, you just need to make sure you update the ACL’s on the CDP locations in LDAP (if you use LDAP) so the new CA can write to the existing objects. It is doable. You just have to watch out for the %2 in your CDP locations as this will put the servers name in it and you are changing it. Make sure when you are finished moving the CA to a server with a new name that you are able to validate all your CDP and AIA locations from a new certificate and an old certificate using: certutil -urlfetch -verify

      1. michael Wright says:

        Hiya,

        We have 2008R2 DC with Enterprise CA installed. We want to migrate the CA to a new member server, with a different name.

        There is this article to follow by MS https://technet.microsoft.com/en-us/library/cc742388(WS.10).aspx

        But I’m concerned about clients renewing there certificates, or authenticating and not finding the CA(CDP and AIA extensions)

        Can the article on this site be followed, or do I follow the article Ive mentioned above?

        what do I do about the CDP and AIA extensions?

        1. Hi Michael,
          This blog here is a (rather quick) way to completely decommission a CA. If I got you right you want to migrate your existing CA, though. Therefore, the guide you identified at https://technet.microsoft.com/en-us/library/cc742388(WS.10) will most likely be more suitable for you. Regarding the CDP and AIA extension please be aware that consumers expect to find the CRL and AIA information for currently issued certificates at the same locations also after the CA has been migrated. Therefore you will most likely need to modify the CA’s configuration to match the paths that were active on the CA before you did the migration. If you compare the Registry-settings on the machine where it is currently running to the settings after the migration the explanation of the different variables here might help: https://technet.microsoft.com/en-us/library/hh831574(v=ws.11).aspx. It might mean that you have to replace a variable like %2 with a hard coded string, e.g. if the server’s name, on which the CA runs changes.
          Hint: Also please be aware that issuing a CRL that is valid for a very long time might mean that consumers cache it for this time span and therefore might not check for a new CRL with updated revocation info during that time span.

Skip to main content