none
Upgrading Certificate Authorities from 2003 SP2 to 2012 R2

    Question

  • We currently have one offline standalone root certificate authority and one enterprise issuing certificate authoritythat are both running Windows Server 2003 Enterprise Edition Service Pack 2. Our current plan is to replace each with a new Server 2012 R2 machine replicating the same set up. We plan on backing up the CA databases, private key, template list, algorithm and CSP and then importing them on the new replacement server. Our initial plan is to use new host names for both servers, which from what I can see complicates things. I planned on editing the registry file exported from the original servers to change and references to old servers before importing, but I'm concerned that this will still cause problems. Specifically with the CRL Distribution Points (CDP) and the Authority Info Access (AIA) locations. We have two CDPs (one for each CA) and each CDP contains the name of the machine name that it is a part of. The CDPs from issued certificates point directly towards URL=http://IssuingCAFQDN/CertEnroll/IssuingCA.crl and the AIA does something similar by pointing towards URL=http://IssuingCAFQDN/CertEnroll/IssuingCAFQDN_IssuingCA.crt.

    A few questions based on that I have found so far:

    Will certificates issued by the existing issuing CA have problems if the new issuing CA has a different machine name and the older server no longer exists in DNS or AD?
    Will adjustments need to be made inside of Active Directory Sites and Services > Services > Public Key Services beyond permission related changes to ensure that the new servers have access to the necessary objects?
    Will the names of the containers within Active Directory Sites and Services > Services > Public Key Services > CDP remain as they are after the upgrade? Currently the CDP container has two child containers.  One is named the same as the root CA (CN=RootCA) and the other is named the same as the issuing CA (CN=IssuingCA), or are these just names of the objects in active directory and not tethered to the servers that share the same name?
    Is it recommended to retain the same machine names instead of using new machine names?

    From reading this (http://blogs.technet.com/b/xdot509/archive/2011/11/17/upgrading-your-pki-from-windows-server-2003-to-windows-server-2008-r2-part-ii-upgrade-considerations.aspx), we will need to edit the CDP and AIA paths and reissue all certificates if we utilize new host names (due to the fact that the paths that exist in the CA utilize the names of the existing CAs). Has anyone encountered that before?
    Wednesday, August 13, 2014 9:23 PM

All replies

  • Re fixing permissions in config container: This is similar to moving the CA to another machine - you just might see the old CA's now unassociated SID listed in the ACLs of objects in Public Key Services.

    Re CDP / AIA:

    The objects in AD have originally been created with the names of that servers but they don't change automatically. This actually makes migration to a CA with a new host name more complicated (if you had used the default CDP and AIA URLs incuding the host names initially which I would not recommend for that reason).

    If you don't change the machine name the new CA can just write to the existing objects (that include the unchanged host name) and you don't have to edit CDP and AIA.

    If you would change the host name and again use the defaults new objects would be created and the CA would per default just publish CRLs to the new one.

    (Only) when the host name has been changed you could:

    (1) also add the "old" URLs (including the old host name) to the config of the new CA but configuring them (as per the checkboxes in Extensions / CDP) for publication only but not for embedding in CDP URLs. So clients trying to validate "old" certificates will find the old locations populated with current CRLs - and you don't have to re-issue client certificates immediately.

    But as new certificates will include new URLs it is not as confusing and after the last cert. signed by old CA will have been expired you could removed the legacy URLs from the config.

    or

    (2) edit all URLs so that the config of the new CA matches the old and thus refers to objects that are named after the old CA. Less URLs but probably confusing in troubleshooting. And probably someday some admin decides to delete an object that is named after an extinct server (I have experienced such things more than once.)

    I would recommend instead (again, only valid for a new name):

    (3) Add the old URLs as described in (1) but replace the new URLs used in AIA and CDP URLs so that they don't refer to the host name at all. This will make future migrations easier.

    Elke


    • Edited by Elke Stangl Thursday, August 14, 2014 8:20 AM
    Thursday, August 14, 2014 8:19 AM
  • Hi Elke. Thank you for your reply!

    Fixing the permissions seems relatively straightforward thankfully.

    It definitely seems that it would be easier to either A) go back in time and set the CA up differently so that the URLs don't have the host name in them or B) utilize the same host names this time around (singnifcantly more likely!). If I make any kind of modifications to the CDP and AIA URLs I will need to reissue all certificates (if I don't choose to add the URLs and DNS entries for the old server pointing to the new server), is that right? As much I would love to adhere to my company's new naming standards, I think the arguement can be made to reuse the old host names to help prevent the need for re-issuing of all certificates (something we will need to do anyways in the next few years for SHA2 compliance but something I do not want to force immediately) or the preventing future problems if an admin deletes a "stale" object from AD / DNS.

    Thursday, August 14, 2014 9:57 AM
  • I thought of a few more questions:

    The URLs point to files that are hosted in the "C:\WINDOWS\system32\certsrv\CertEnroll" directory on my issuing CA.

    -If we use new machine names, should the new issuing CA use the same IP as the previous issuing CA server?

    -Are these files copied over in the process of baking up and restoring the CA settings using the Certificate Authority backup and restore functionality? If not, can they can just be copied over?

    -If we do choose to use new machine names and use DNS entries (for the old issuing server machine name redirecting to the new server's IP) to maintain the validity of the existing AIA and CDPs and add two new CDPs for the new servers, will new certificates have four CDPs and further require us to maintain the DNS entries for the old issuing server?

    Thursday, August 14, 2014 10:57 AM
  • Re re-issuance of certificates:

    You don't have to re-issue the certificate in either case if you are willing to live with a more confusing set of URLs in case you change the name.

    If you don't change the host name you don't have to change AIA and CDP URLs anyway.

    If you change the host name you could have two sets of URLs in your config:

    CDP:

    [Old URLs referring to old host name] --> configured only for publication of CRLs, will not show up in new certificates but the new CA keeps populating the old URLs "silently". For HTTP, you need to create / change your FTP scripts and/or your file: publication URL.

    [New URLs referring to new host name]  --> configured for publication (if possible, not HTTP) and for embedding in new certificates.

    AIA:

    You don't need to add the old AIA as you don't publish any new files there but you need to keep the old AIA populated.

    As for the other questions:

    Same IP as old CA? I would rather edit the DNS record so that the new CA would host both old and new HTTP URLs.

    CRLs / CRTs copied on restore?

    CDP:

    They are not copied but re-created if you use the same certificate and key. The files might be given different default names in the CertEnroll folder that use the new name. So keeping the old URLs in place you would need to copy the new files also to files with the old names - I would use an additional file://
    But note that when you used the default settings CRL file names don't include the host name, only CRT files do. So unless you had changed the default settings at the old CA this will most likely not be required.

    AIA:

    With ATA you need to copy the re-created CRT file to a file with the old name and rename it once.

    No, new certs. will not include the old CDPs as you would configure the old URLs only for publication, not for embedding in certificates.


    • Edited by Elke Stangl Thursday, August 14, 2014 11:45 AM
    Thursday, August 14, 2014 11:43 AM
  • Thanks again for replying.

    So roughly this is what I feel I should do:

    1. Power on root ca, attach temporarily to network
    2. Backup CA database, private key, template list, algorithm and CSP from old root CA
    3. Remove certificate services role from old root ca
    4. Rename old root CA
    5. Power off old root CA
    6. Power on new root ca, temporarily attach to network
    7. Rename new root CA to match old root CA's host name
    8. Install certificate services role on new root ca and import CA database, private key, template list, algorithm and CSP exported from old root ca
    9. Start and stop the "Certificate Services" service on the new root ca
    10. Power off the new root ca, remove from network
    11. Backup CA database, private key, template list, algorithm and CSP from old issuing CA
    12. Remove certificate services role from old issuing ca
    13. Remove old issuing ca from domain
    14. Rename new issue ca to match old issueing ca's host name, reboot it
    15. Join new issuing ca to domain
    16. Install certificate services role on new issuing ca and import CA database, private key, template list, algorithm and CSP exported from old root ca
    17. Modify permissions on AIA and CDP objects to ensure that new server objects have the necessary permissions, removing old server SIDs if still present
    18. Copy old files over to new "...certsrv\CertEnroll" folder if they are not already present
    19. stop and start

    A few questions:

    • Since we would be reusing the same server names, do the CDP and AIA paths need to be modified at all?
    • If we retain the same server names, do the files from "...certsrv\CertEnroll" need to be copied over or would they be automatically created?
    • If we do modify the paths and maintain a DNS record for the old host name pointing to the new server's IP address, we would modify both the AIA and CDP records to point to the new server and keep the files located where they can be accessed by the old certificates so that they do not need to be reissued?
    • Edited by Alex Church Thursday, August 14, 2014 12:41 PM
    Thursday, August 14, 2014 12:41 PM
  • The list is fine!

    I am just missing a backup and restore of the CAs' registry keys and/or scripts that had been used for configuration (and/or checklist with settings such as CRL life times). When migrating to a new OS you would have to edit the reg file so that it only includes the settings you have changed.

    I would also backup the certsrv folder "for comparison" (It should not be needed, see below) and I generally recommend to create a CRL with an extended life time manually with cerutil -sign (you can publish this CRL if the migration takes longer than expected.)

    Re your questions:

    • Since we would be reusing the same server names, do the CDP and AIA paths need to be modified at all?

      Thee CDP and AIA paths do not need to be modified. But the default settings in terms of which CDP and AIA URLs are activated in the CA configuration do differ in W2K12. So the URLs available in the config are the same, but the checkboxes are different.
      So you don't have to edit the paths but you have to check / uncheck those checkboxes. You could also the compare the numbers (prefixes) of the values in the CRLPublicationURLs and CACertPublicationURLs registry keys from a backup of the old CA.
      If you had use a custom URL (such as a file:// URL to publish to another web server) you would need to edit CDP to "restore" this. Same for changing setting re delta CRLs, e.g. turning off delta CRLs.
      So you should not rely on CDP and AIA (including the checkboxes) being the same but do a step-by-step check of each URL incl. the prefix after the migration.
    • If we retain the same server names, do the files from "...certsrv\CertEnroll" need to be copied over or would they be automatically created?

      They would be re-created with the same names. But again - if you had e.g. turned off delta CRLs at the old CA you will not see a CA+.crl file at the old CA but there will be one at the new CA. The settings for these files are determined by the CDP and AIA publication settings.
    • If we do modify the paths and maintain a DNS record for the old host name pointing to the new server's IP address, we would modify both the AIA and CDP records to point to the new server and keep the files located where they can be accessed by the old certificates so that they do not need to be reissued?

      You should not need to modify AIA and CDP URLs if you use the same host name and if you had used the default settings with Windows 2003. So as soon as the TTL of the DNS record has elapsed validating apps. should be able to use the "new" CDP and AIA.
      Test with certutil -verify -urlfetch immediately after the migration!

    Elke


    Thursday, August 14, 2014 8:57 PM
  • Thanks for your reply Elke.

    I did have backing up the registry settings already in my documentation, just forgot to add them here. I will be backing up the following items:

    1. C:\WINDOWS\CAPolicy.inf
    2. C:\WINDOWS\certsrv
    3. C:\WINDOWS\CertLog (likely redundant as I believe this is what is backed up when you back up the CA from the snap-in but I will be grabbing it anyways).
    4. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc
    5. CA Database
    6. Private Key
    7. Template List (for the issuing CA)

    We will be operating within the window of time where our CRLs will be valid, is publishing an extended life CRL necessary?

    I have documented all CDP and AIA settings on each CA. When the upgrade has been completed (role installed, registry settings imported, ca database restored, the service stopped, and service started) I should validated that all the check boxes are as they should be?

    We do not currently utilize file:// for CRLs, that I have read is not a best practice.

    I will certainly add "certutil -verify -urlfetch" to our test plan, thank you!

    We will be exporting a list of templates from our issuing CA and importing them on the new issuing CA (using certutil -setcatemplates + <templatelist>). Is this what adds templates to the issuing CA's managed templates list? or does that need to be done manually post-upgrade?

    Jumping from 2003 SP2 to 2012 R2 I know there are a lot of new features that have been added to Certificate Services, are there any that will activate automatically post-upgrade that we should be concerned about?

    Wednesday, August 20, 2014 5:43 PM