Performing the Upgrade or Migration

Applies To: Windows Server 2008

There are various tasks that need to be performed based on the type of migration or upgrade scenario you are following. These tasks were first introduced in "Tasks Required for Key CA Upgrade and Migration Scenarios" in Planning the Upgrade or Migration.

Scenarios and Related Tasks

The common upgrade and migration scenarios are described as follows:

• Hardware change

  Move a certification authority (CA) from one computer to a different computer with a different hardware or operating system. This includes:

  • x86 to x64

  • Physical computer to virtual computer (including Virtual Server and Hyper-V™)

  • Single computer to Windows® failover cluster

  • Enterprise edition to Standard edition

• Host name change

  Move a CA from one computer to a computer with a different host name.

• CA type change

  Move a CA from one installation type to another. This includes:

  • Stand-alone CA to enterprise CA

  • Enterprise CA to stand-alone CA

• Domain membership change

  Change the domain membership attributes of a CA, either on the same computer or in combination with moving the CA from one computer to another:

  • Workgroup computer to domain member

  • Domain member to workgroup computer

  • Domain to different domain (in same forest)

• Migrate a CA from a domain controller

  This migration scenario has two subcomponents:

  • Move a CA on a domain controller to a CA on a domain member (demoting a domain controller).

  • Move a CA on a domain controller to a CA on a different computer (migrating a CA).

• Windows version or edition change

  This migration scenario has two subcomponents:

  • In-place upgrade of Windows Server® 2003 to Windows Server 2008

  • In-place upgrade of Windows Server from the Standard edition to the Enterprise edition

The following table lists the tasks required for each scenario.

Migration and upgrade tasks

Scenario	Required tasks
Hardware change	CA backup CA configuration backup Uninstall services Install CA CA restore
Host name change	CA backup CA configuration backup Uninstall services Install CA CA restore Active Directory® cleanup
CA type change	CA backup CA configuration backup Uninstall services Install CA CA restore
Domain membership change	CA backup CA configuration backup Uninstall services Install CA CA restore Active Directory cleanup
Move a CA on a domain controller to a CA on a domain member (demoting a domain controller)	CA backup CA configuration backup Uninstall services Demote domain controller Install CA CA restore
Move a CA on a domain controller to a CA on a different computer (migrating a CA)	CA backup CA configuration backup Uninstall services Install CA CA restore Active Directory cleanup
In-place upgrade of Windows Server 2003 to Windows Server 2008	Version upgrade Upgrade templates in Active Directory Domain Services (AD DS)
In-place upgrade from Windows Server 2008 Standard to Windows Server 2008 Enterprise	Edition upgrade

The tasks can be divided into three categories:

• Preparing the Source Environment

  This consists of creating backups of the components required for migration and then exporting the components from the source environment.

• Completing the Upgrade or Migration

  This consists of installing and importing the required components into the target environment.

• Performing Post-Upgrade or Post-Migration Tasks

  This includes making required configuration changes in the target environment or elsewhere to complete the migration.

Each task is described in detail in subsequent sections.

The following tasks are not included in the table but are recommended for every migration or upgrade.

• Publishing a CRL with a Long Validity Period

• Performing a Complete Server Backup

• Verifying Security Settings (after the migration or upgrade)

A real-world scenario may require tasks from more than one of the following individual scenarios. In this case, combine the tasks from all of the relevant rows.

Scenarios that are not listed in the table, such as changing the language of the Windows version that the CA is running, or migrating a CA to a separate Active Directory forest, are not supported at this time.

Example: Moving a CA from a Domain Controller

The requirement to move a CA from a domain controller is a common scenario but has some considerations that need to be understood and addressed.

The following options present sets of tasks to achieve this goal in two possible ways. Step-by-step procedures for completing the tasks are included following the options.

Option A: Migrate the CA to a New Host

The first option is to migrate the CA component to another computer and to keep the domain controller component in place on the original host. Because the original computer will stay on the network, the CA must be moved to a server with a different host name.

The tasks for migrating the CA to a new host are as follows:

1. Verify that the correct permissions and prerequisites are in place.

2. Perform the steps for preparing the source environment as follows:

   • Publish a CRL with a long validity period (optional).

   • Perform a complete server backup.

   • Perform a CA backup.

   • Perform a backup of the CA configuration.

   • Uninstall the CA from the original host. Use the Add/Remove Windows Components wizard in Windows Server 2003 or the Server Manager Add Role Services Wizard in Windows Server 2008.

3. Perform the following steps for the migration:

   • Install the CA on the target computer (using the CA certificate that was backed up in the previous step 2).

  - Once this step is complete, if you have not yet taken the source CA offline, there will be two CAs in the environment with the same CA name. However, if the target CA is an enterprise CA, the enrollment information in AD DS was overwritten when you installed the target CA. Therefore, if you were to perform a test enrollment at this time, the certificate would be issued by the new CA. If the target CA is a stand-alone CA, the certificate enrollment tool (such as certreq.exe) would allow you to choose which CA should receive the request.  
      
  - Restore the CA database and configuration on the target computer.  
      

4. Perform the steps for post-migration as follows:

   • Update CRL distribution point and authority information access extensions after a host name change.

   • If necessary, verify the ACLs on the new CA certificate and CRL publishing locations that were previously configured and ensure that the new CA computer has permissions to write to them.

   • Perform registry cleanup after the host name change.

5. Perform the steps for upgrading certificate templates in AD DS (optional).

   This is required only if at least one CA in the forest has been upgraded to Windows Server 2008 and one of the new Windows Server 2008 templates is required.

6. Perform the steps for verifying security settings as follows:

   • Verify CA security settings.

   • Verify Active Directory permissions for the CA.

Option B: Keep the CA on the Original Host and Move the Domain Controller

The second option is to keep the CA in place on the original host and move the domain controller role to another host.

The tasks for this option are as follows:

1. Install a new domain controller on the network and allow AD DS to replicate (optional).

   This step is only required if there is not another domain controller in the environment.

2. Perform the following steps for preparing the source environment:

   • Perform a complete server backup.

   • Perform a CA backup.

   • Perform a backup of the CA configuration.

3. Perform the following steps for completing the migration:

   • Uninstall the CA from the original domain controller or CA computer.

   • Demote the domain controller on the original domain controller or CA computer and, optionally, take it offline.

4. Prepare a new server with the same host name as the original domain controller or CA computer (optional).

   This step is required only if a hardware change for the CA is required; for example, if the CA needs to be moved to a server with an x64-based architecture.

5. Perform the following step for the upgrade:

   • Install the CA on the target computer (either the original host or the host installed in the previous step 4) by using the CA certificate exported in the previous step "Perform a CA backup."

6. Perform the following steps to restore the CA database and configuration on the target computer:

   • Restore the CA database.

   • Restore the CA registry configuration settings.

   • Restore the certificate template configuration (reassign templates to the CA).

   Because the host name has not been changed, the post-migration steps listed previously should not be required. However, performing a final check of the configuration is recommended.

7. Upgrade certificate templates in AD DS (optional).

   This is required only if at least one CA in the forest has been upgraded to Windows Server 2008 and one of the new Windows Server 2008 templates is required.

8. Perform the steps for verifying security settings as follows:

   • Verify CA security settings.

   • Verify Active Directory permissions for the CA.

For more information, see the Active Directory Domain Services and DNS Server Migration Guide.

Upgrade and Migration Tasks

The topic provides step-by-step procedures for the upgrade and migration tasks previously discussed.

Verifying Permissions

The permissions required to perform a migration depend on the individual tasks performed. Membership in the Enterprise Admins group is required to install an enterprise CA, but it is not required for an upgrade because the CA already has permissions to update any required Active Directory objects.

On a server that is a domain member, the user who installs an enterprise CA must be a member of both the root Domain Admins group and the Enterprise Admins group. This set of permissions is required for any enterprise CA installation, and it assumes that the Enterprise Admins group or Domain Admins group is also a member of the local server's Administrators group. To install a stand-alone CA, only local administrator privileges are required.

For migrating archived encryption keys from one CA to another, the key recovery agent keys are required.

If a hardware security module (HSM) is used to protect the CA keys, access to the HSM administration smart cards is required.

The specific permissions required are documented in each of the following migration and upgrade tasks.

Preparing the Source Environment

Before initiating an upgrade or migration, ensure that you have taken the following steps to mitigate the risk of downtime.

Publishing a CRL with a Long Validity Period

Before starting with a CA migration procedure, it is highly recommended that you publish, for each CA certificate, a CRL with a sufficiently long lifetime to ensure that client computers can verify certificates while the CA is unavailable.

This step is of particular importance when updating the root CA because of the large number of certificates that could potentially be affected by a CRL outage.

The lifetime of the CRL should include at least the duration that is planned for the migration. It is a good practice to allow a margin of error in case the migration takes longer than intended. It may be possible to sign a CRL again with the CA key manually, but it is a good practice not to depend on this possibility.

If the CA is to be decommissioned, set the CRL lifetime to the remaining validity period of the longest valid CA certificate.

To set the validity time and publish a CRL

1. Log on with local administrative credentials to the CA computer.

2. Click Start, click Run, and type certsrv.msc to open the Certification Authority snap-in.

3. In the console tree, click the Revoked certificates folder. On the Action menu, click Properties.

4. After recording its original value, set the CRL publication interval by using the previous guidance, for example, to 7 days for a standard CA migration. In the case of CA decommission, set the interval to 99 years. The CA will automatically set the CRL expiration date to the date of the CA certificate expiration.

   

5. Clear the Publish Delta CRLs check box. This is important because a base CRL is invalidated if delta CRLs are configured but not available or up to date.

6. Click OK.

7. In the console tree, ensure that Revoked certificates is selected.

8. On the Action menu, point to All Tasks, and then click Publish.

9. Make sure that only New CRL is enabled, and click OK.

To verify the CRL publication

1. Open a command prompt.

2. At the command prompt, change to the local directory where the CRLs are published. By default, this is %windir%\system32\CertSrv\CertEnroll.

3. Make sure that there is at least one file with the CRL extension that has a time stamp equal to the time when you published the CRL in the previous task.

4. Open the CRL file for each CA certificate, and verify that the Next CRL Publish extension shows the current date plus the time configured as CRL publication interval on the Revoked Certificates Properties page (see the previous figure), or the expiration date of the CA certificate in the case of a decommission.

5. Close the CRL file.

6. Ensure that all CRL files have been copied to the CRL distribution points as required.

Performing a Complete Server Backup

A complete server backup (system state backup in Windows Server 2003 or Windows backup in Windows Server 2008) should be performed before a migration to allow for a quick recovery of an existing CA if necessary. The actual migration will be performed by using a CA backup created as a separate step.

For more information about creating backups in Windows Server 2008, see Step-by-Step Guide for Windows Server Backup in Windows Server 2008 (https://go.microsoft.com/fwlink/?LinkId=119141).

The system state backup is available in Windows Server 2003 but not in Windows Server 2008.

For more information about creating system state backups in Windows Server 2003, see article 326216 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkId=117369).

Performing a CA Backup

A CA backup is required if you are going to perform a migration, such as in the following scenarios:

• CA type change

• Domain membership change

• Domain role change

• Hardware change

• Host name change

The CA backup consists of two entities:

• CA database

• CA certificate and keys

CA Database Backup

The CA database and log files can be backed up by using the Certification Authority snap-in or the Certutil.exe command-line tool.

To use the Certification Authority snap-in to create a backup of the CA database and, optionally, the CA certificate and private key

1. Choose a backup location and attach media, if necessary.

2. Log on with local administrative credentials to the CA computer.

3. Open the Certification Authority snap-in.

4. Right-click the node with the CA name, point to All Tasks, and then click Back Up CA.

5. On the Welcome page of the CA Backup wizard, click Next.

6. On the Items to Back Up page, select the Private key and CA certificate and Certificate database and certificate database log check boxes, enter the backup location, and then click Next.

7. On the Select a Password page, enter a password to protect the CA private key, and click Next.

8. On the Completing the Backup Wizard page, click Finish.

After the backup completes, note the set of files that have been created in the backup location you chose. There should be a CAName.p12 file, which contains the CA certificate and private key, and a set of database files (certbkxp.dat, edb*#####*.log, CAName.edb) in a folder named Database.

To perform a CA database backup by using Certutil.exe, enter the following command on a computer running Windows Server 2003 or Windows Server 2008:

certutil -backupdbBackupDirectory

BackupDirectory can be a relative or absolute path name and does not necessarily have to exist. For example, if you enter the command certutil -backupdb ".", the database is backed up into a subdirectory named Database within the current directory. The backup command creates the directory specified as BackupDirectory if required, as well as the Database directory. To override an existing backup, specify the -f option:

certutil -f –backupdbBackupDirectory

CA Key Export

If you already performed the previous CA database backup step, and you selected both Private key and CA certificate and Certificate database and certificate database log on the Items to Back Up page, you have already performed the CA key export and you can skip this step. Make sure that you note the CSP and algorithm, in case you need them later (see the following procedure).

If you have not yet exported the CA certificate and key, and if you are not using an HSM, you can use the CA Backup Wizard to export and back up the CA private key by using a procedure similar to the CA database backup procedure documented previously. Select only the Private key and CA certificate check box on the Items to Back Up page.

To back up the CA key by using Certutil.exe, type:

certutil -f –backupkeyBackupDirectory

To protect the CA key, a password must be specified interactively.

In a migration, you may need to know the signature algorithm and the name of the cryptographic service provider (CSP) when installing the CA in the target environment. You can get this information from the .pfx file created in the previous step or from the CA configuration. To get the information from the .pfx file, type:

certutilFileName.pfx

You must specify the password that was entered to protect the .pfx file upon export from the source CA. Search for "Signature algorithm" and "Provider" in the output and record the settings for each.

To determine the CSP and hash algorithm from the CA configuration, enter the following command on the CA:

certutil -getreg ca\csp\*

Performing a Backup of the CA Configuration

The CA configuration must be backed up separately because it is not included in the CA database or key backup.

The CA configuration consists of the settings that are stored in the local registry on the CA and the settings that are stored for the CA in AD DS.

Exporting Registry Configuration

In Windows Server 2003 and Windows Server 2008, the local configuration settings used by the CA are stored in the registry. The following steps should be performed on the source CA.

To export the settings

1. Click Start, point to Run, and type regedit to open the Registry Editor.

2. In HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc, right-click Configuration, and then click Export.

3. Enter a location and file name, and then click Save. This creates a .reg file with the registry configuration information for your CA.

Alternatively, you can type the following command at a command line to back up the registry settings:

reg export HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\ConfigurationFileName**.reg**

FileName is the name of the output file that will contain all CA configuration registry keys in plaintext.

Certificate Templates Assigned to an Enterprise CA

An enterprise CA can have certificate templates assigned to it. You should record the assigned certificate templates before beginning the CA migration. The information is not automatically backed up as part of the CA database or configuration backup. Certificate templates and the association between enterprise CAs and certificate templates are stored in AD DS.

You can determine the certificate templates assigned to a CA by using the Certification Authority snap-in or the Certutil.exe command-line tool.

To list the certificate templates for an enterprise CA by using the Certification Authority snap-in

1. Log on with local administrator permissions to the CA computer.

2. Open the Certification Authority snap-in.

   

3. In the console tree, click Certificate Templates.

   The assigned certificate templates appear in the details pane.

To list the certificate templates for an enterprise CA by using the command line

• On the enterprise CA at a command prompt, type:

  certutil –catemplates > templates.txt

  The list of assigned templates will be saved in the templates.txt file.

  If no certificate templates are assigned to the CA, a failed message 0x80070490 (Element not found) appears.

Certificate Manager Restrictions

Certificate manager restrictions provide a mechanism to control which certificate managers can or cannot approve certificate requests from certain requestors.

Certificate manager restrictions are maintained as a permission property on the CA object in AD DS.

To determine the configured certificate manager restrictions

1. Log on with local administrative credentials to the CA computer.

2. Open the Certification Authority snap-in.

3. Select the CA name. On the Action menu, click Properties.

4. In the CA properties dialog box, click the Certificate Managers Restrictions tab.

5. Record the groups, users, or computers to manage.

Exporting Archived Encryption Keys (Optional)

Exporting and preserving archived encryption keys is necessary only if a CA consolidation is performed or if the original CA will not be preserved. In this case, any encryption keys archived within the CA's database must be preserved to ensure that content encrypted with those keys remains recoverable.

All archived encryption keys must individually be exported from the CA database and imported into the target CA, using the following steps or a similar method. The following steps are offered as one suggested method of retrieving the archived keys. For more information about key archival and recovery, see Key Archival and Management in Windows Server 2008 (https://go.microsoft.com/fwlink/?LinkID=92523).

As a first step, a user with Issue and Manage Certificates permissions on the CA has to retrieve the serial numbers of all certificates that have been marked for key recovery.

To verify the Issue and Manage Certificates permissions

1. Log on with local administrative credentials to the CA computer.

2. Open the Certification Authority snap-in.

3. In the console tree, select the CA name. On the Action menu, click Properties.

4. In the CA properties dialog box, click the Security tab.

5. Verify that the user account that will retrieve the serial numbers and the archived keys from the CA database in steps 8 and 9 has Issue and Manage Certificates permissions.

6. Click OK, and close the Certification Authority snap-in.

7. Open a command prompt, and change the path to a working directory.

8. Query the list of serial numbers of all certificates that have an archived key associated with them. At the command prompt, type the following command as a single line:

   certutil -view -restrict "KeyRecoveryHashes>0" -outSerialNumber | **findstr /C:"SerialNumber: " >**sn.txt

   Sn.txt is the name of the output file you want to contain the resulting list of serial numbers.

9. The resulting list of serial numbers can then be used as the input for the command to retrieve the key binary large objects from the CA database. The binary large object contains a certificate chain and an associated private key, still encrypted to one or more key recovery agent certificates. For example, a command similar to the following could be used to read the output file created above and to recover certificates and private keys:

   for /f "delims=: tokens=2" %i in (sn.txt) do certutil -getkey %i %i.bin

   The outcome of this command is a set of binary files containing the recovered certificates and private keys. The private keys are still encrypted with one or more key recovery agent keys at this point.

10. The binary large objects must now be decrypted with a key recovery agent's key. Make sure that you are logged on with a user account that has access to the correct key recovery agent certificate and keys. To determine which key recovery agent keys are required to decrypt a binary large object, run the following command:

    certutil -getkey "serialnumber"

    Replace serialnumber with the serial number of the certificate whose key must be recovered.

    The Recipient Info section at the end of the output of this command should contain the serial numbers of the key recovery agent certificates that can be used to decrypt the binary large object.

11. To convert the binary large object files created in the step above into .pfx files, you can use a command similar to the following:

    for %i in (*.bin) do certutil -p YourPassword -recoverkey %i %i.pfx

    Or, you can use the following command on each file:

    certutil –p YourPassword -recoverkey FileName.bin FileName.pfx

    Replace YourPassword with a secure password to protect the .pfx file in transit, and replace FileName with the file name of the input .bin file and the output .pfx file, respectively.

12. Once the .pfx files have been created, keep them in a secure vault. You will need these files when applying the steps described in Performing a Restore of Encryption Keys.

Completing the Upgrade or Migration

Completing an AD CS upgrade or migration includes the following primary tasks:

• Uninstall services.

• Demote a domain controller.

• Remove a server from the domain.

• Upgrade Windows.

• Join a server to a domain.

• Install the CA on the target computer.

• Restore the CA database and configuration.

The particular tasks you perform will depend on your organization's needs.

Uninstalling Services

In all Certificate Services migration scenarios, the existing role service should be uninstalled after backing up Certificate Services. Uninstalling the service is recommended to avoid conflicts between the old and the new instance of the service. Configuration settings in AD DS or the CRL distribution point may be reused by the new service.

If a CA is installed on a domain controller, the CA must be uninstalled before the domain controller can be demoted.

Uninstalling the CA

When migrating a CA from a domain controller, if the domain controller will be demoted and removed from the environment, the CA must first be uninstalled.

To uninstall the CA on a computer running Windows Server 2003, use the Add/Remove Windows Components wizard.

To uninstall the CA on a computer running Windows Server 2008, use the Remove Roles Wizard in Server Manager.

Uninstalling Web Enrollment Support

If Web enrollment support is installed on a computer running a CA, disable the Web enrollment role service and optionally uninstall Web enrollment support and IIS.

To disable the Web enrollment role service on a computer running AD CS or Certificate Services

1. Log on with local administrative credentials to the CA computer.

2. At a command prompt, type:

   certutil -vroot delete

To remove Web enrollment support, use the Add/Remove Windows Components wizard for Windows Server 2003 or Server Manager for Windows Server 2008.

Demoting a Domain Controller

A CA can be migrated from a domain controller to another computer by performing a CA migration with a host name change, preserving the domain controller in place. If, however, you want to remove the domain controller role while preserving the CA on the original host, the domain controller role can be removed instead. The process is similar to a migration because the CA service must be uninstalled before the domain controller can be demoted; the CA service can then be reinstalled.

For more information, see article 276239 (https://go.microsoft.com/fwlink/?LinkId=117370) and article 241201 (https://go.microsoft.com/fwlink/?LinkId=117371) in the Microsoft Knowledge Base.

To demote a Windows Server 2003 domain controller

1. Log on with administrative credentials to the CA computer.

2. Click Start, click Run, and type dcpromo.

3. Click Next.

4. Decide if this is the last domain controller in the domain, and click Next.

5. Set the password for the local administrator account, and click Next twice.

6. Click Finish.

7. Restart the computer.

To demote a Windows Server 2008 domain controller

1. Log on with administrative credentials to the CA computer.

2. Click Start, click Run, and type dcpromo.

3. Click Next.

4. If the computer is a global catalog server, make sure that other global catalog servers exist in your environment, and click OK.

5. Decide if this is the last domain controller in the domain, and click Next.

6. If the computer holds the last copy of directory partitions, click Next to delete them.

7. If appropriate, accept the deletion of all directory partitions on the domain controller, and click Next.

8. Remove Domain Name System (DNS) delegations, and click Next.

9. Set the local administrator password, and click Next.

10. Click Next to accept the summary.

Removing the Server from the Domain

Removing a computer from the domain is required, for example, if the computer should be moved to a different domain.

To remove the server from the domain

1. Log on with local administrative credentials to the CA computer.

2. Click Start, click Run, and type sysdm.cpl to open System properties.

3. Click the Computer Name tab.

4. Click Change.

5. Click Workgroup, enter a workgroup name that is not the same as a domain name in your network, and click OK.

6. In the Credentials dialog box, click OK.

7. Click OK three times.

8. Click Yes to restart the computer.

Removing a server from a domain does not remove the computer object from AD DS or Active Directory. You should remove the computer object manually from the domain.

Upgrading Windows

An upgrade is a straightforward task that can be performed with relatively little effort because all configuration settings are preserved during the upgrade process.

A complete server backup of the CA computer is highly recommended before an in-place upgrade is started.

In addition to the CA, the other AD CS role services (Web enrollment and the Network Device Enrollment Service) are upgraded along with the operating system upgrade.

Joining the Server to a Domain

Joining a CA computer to a domain is mandatory if an enterprise CA should be installed on the computer.

To join the server to a domain

1. Log on with local administrative credentials to the CA computer.

2. Click Start, click Run, and type sysdm.cpl to open System properties.

3. Click the Computer Name tab.

4. Click Change.

5. Click Domain, type the domain name, and then click OK.

6. Type the credentials that have permissions to join a computer to the domain, and click OK.

7. Click OK three times.

8. Click Yes to restart the computer.

Installing the CA on the Target Computer

Most migrations involve installing AD CS or Certificate Services on the target computer, using the same CA keys and CA name as the source CA.

If the target CA is an enterprise CA, or a stand-alone CA installed by an enterprise administrator on a domain member computer, the Active Directory objects will be overwritten as part of the installation process.

For information about installing a target CA as a clustered CA, see Configuring and Troubleshooting Certification Authority Clustering in Windows Server 2008 (https://go.microsoft.com/fwlink/?LinkId=119142).

Windows Server 2003

To set up a CA on Windows Server 2003

1. Log on with local or enterprise administrator permissions to the CA computer.

2. Click Start, point to Control Panel, click Add or Remove Programs, and click Add/Remove Windows Components (or at a command prompt, type appwiz.cpl).

3. Select Certificate Services, accept the warning message that the computer name and domain membership cannot be changed once the CA is installed, and click Next.

4. Select the CA type, select the Use custom settings to generate the key pair and CA certificate check box, and then click Next.

5. At this stage, you have a choice between creating a new certificate and key for the new CA or importing a key and certificate from a .pfx file. Use the second option for a migration.

   • Click Next to create a new CA certificate and key.

   • If performing a migration, click Import. Locate and select the .pfx file exported from the source CA, and specify the password you selected when exporting the CA certificate and key from the source CA. Click OK and select the newly imported key from the list of existing keys. To use the certificate from the .pfx file with the key, select the Use the certificate associated with this key check box.

6. Select the CSP and hash algorithm that you noted in the "Performing a CA Backup" procedure, and click Next.

7. If the CA is installed on a workgroup computer, optionally set the distinguished name suffix, and click Next.

8. Specify the certificate database, and click Next.

9. If you are installing a subordinate CA, select whether to save the certificate request or submit it directly to the CA and click Next.

10. Once the installation has ended, click Finish.

11. Click Close, and restart the computer.

Windows Server 2008

To set up a CA on a computer running Windows Server 2008

1. Log on with local or enterprise administrator permissions to the CA computer.

2. Click Start, click Run, type servermanager.msc, and then press ENTER to open Server Manager.

3. In the console tree, click Roles.

4. On the Action menu, click Add Roles.

5. If the Before you Begin wizard appears, click Next.

6. In the list of available server roles, select the Active Directory Certificate Services check box, and click Next twice.

7. Make sure that Certification Authority is selected, and click Next.

8. Choose if you are migrating to an enterprise or stand-alone CA, and click Next.

9. Specify either Root or Subordinate CA, depending on the source CA, and click Next.

10. At this stage, you have a choice between creating a new private key or using an existing private key. Use the second option for a migration.

    • To create a new CA certificate and key, select Create a new private key.

    • For a migration, on the Set Up Private Key page, select Use existing private key.

      

    • Click Select a certificate and use its associated private key, and click Next.

    • If the CA certificate has been installed on the computer, it will be listed in the Certificates box. Otherwise, click Import to import a certificate from the .pfx file created by exporting the CA certificate and private key from the source CA.

    • Click Browse, and locate and select the file containing the certificate and private key exported from the source CA.

    • Enter the password you selected when exporting the CA certificate and key from the source CA, and click OK.

  - Complete the rest of the installation wizard to finish installing AD CS.

  - Click **Yes** to accept the warning to overwrite AD DS. (This appears only if you are installing an enterprise CA.)

  - If the CA is installed on a workgroup computer or an existing private key was reused, optionally set the distinguished name suffix, and click **Next**.

  - If the CA is a new root CA, set the validity period for the certificate generated on the CA, and click **Next**. Otherwise, skip this step.

  - If required, configure the database location paths, and click **Next**.

  - If you are installing a subordinate CA, select whether to save the certificate request or submit it directly to the CA, and click **Next**.

  - To install AD CS, click **Install**.

Restoring the CA Database and Configuration on the Target Computer

Restoring a CA consists of the following tasks:

• Restore the CA database.

• Restore the CA registry configuration.

• Restore the certificate template configuration and other settings.

• Configure and verify security settings.

On the target computer where a CA has already been installed, perform the tasks in the order shown. Restoring the CA database and configuration assumes that a CA has been installed with the default parameters. The configuration will be overwritten with the settings from the CA configuration backup.

Restoring the CA Database

To import the CA database from the source CA to the target CA by using the Certification Authority snap-in

1. Log on with administrative credentials to the target CA computer.

2. Open the Certification Authority snap-in.

3. Right-click the node with the CA name, point to All Tasks, and then click Restore CA. Click OK to confirm stopping the CA service.

4. In the CA Restore wizard, on the Welcome page, click Next.

5. On the Items to Restore page, select Certificate database and certificate database log. Click Browse, and navigate to the location of the Database folder that contains the CA database export files created when you previously exported the CA database.

6. Enter the password you used to export the CA database from the source CA, if a password is requested.

7. Click Finish, and then click Yes to confirm restarting the CA.

To restore the CA database by using the command line

1. At a command prompt, type certutil -shutdown to shut down the CA service.

2. At the command prompt, type certutil -databaselocations to find the name of the database currently in use by the CA.

   By default, the CA database is stored in the %windir%\system32\CertLog directory.

3. Move the default database directory to a different directory on your system to keep the existing database for safety purposes.

   By default, the CA database is stored in the %windir%\system32\CertLog directory.

4. Create an empty folder with the same name as the folder you moved in the previous step. For example, if you have moved the CertLog directory from %windir%\system32\CertLog to \temp, you must re-create the CertLog folder in the %windir%\system32 directory.

   If you want to let the restore command override the existing database, you must specify the -f option with the -restoredb command in the next step.

5. To restore the database, type certutil -restoredbBackupDirectory.

   Replace BackupDirectory with the name of the directory that contains the database directory and the directory to use for the database backup.

   The -f option (certutil -f -restoredb) is optional to override the database that is currently in use by the CA. For example, if you have stored the database under a directory called MyCA, you must specify MyCA as a parameter for the -restoredb command.

6. To start AD CS after the database was restored, type the following command at the command prompt:

   net start certsvc

Restoring the CA Registry Configuration

The CA configuration information is stored in the registry in: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc

Before importing the registry settings from the source CA to the target CA, create a backup of the default target CA registry configuration by using the procedure Exporting Registry Configuration. Be sure to perform these steps on the target CA and to name the registry file a name such as "DefaultRegCfgBackup.reg" to avoid confusion.

A suggested way of performing the registry configuration import is first to open the registry file you exported from the source CA in a text editor and analyze it for settings that may need to be changed or removed.

To analyze the registry file

1. Right-click the .reg file created by exporting the settings from the source CA.

2. Click Edit to open the file in a text editor.

3. If the target CA's computer name is different from the source CA's computer name, search the file for the host name of the source CA computer. For each instance of the host name found, ensure that it is the appropriate value for the target environment. Change the host name, if necessary. Update the CAServerName value.

4. Check any registry values that indicate local file paths, such as the following, to ensure drive letter names and paths are correct for the target CA. If there is a mismatch between the source and the target CA, either update the values in the file or remove them from the file so that the default settings are preserved on the target CA.

   These storage location settings are elected during CA setup. They exist under the Configuration registry key:

   • DBDirectory

   • DBLogDirectory

   • DBSystemDirectory

   • DBTempDirectory

   The following settings under the Configuration\{CA Name} registry key contain, in their default values, a local path. (Alternatively, you can update these values after importing them by using the Certification Authority snap-in. The values are located on the CA properties Extensions tab.)

   • CACertPublicationURLs

   • CRLPublicationURLs

5. You can remove any registry values that you do not want to import into the target CA.

Once the text file is edited, it can be imported into the target CA. Alternatively, you can import the entire set of registry settings into the target system and then validate and update them by using the Registry Editor.

To import the registry settings from the .reg file to the target CA

1. On the target CA, use the Certification Authority snap-in to stop the CA service.

2. Double-click the .reg file previously edited to open the Registry Editor.

3. Confirm that the registry keys were imported, and close the Registry Editor.

4. Restart the CA.

5. Use the Registry Editor to verify any settings that were changed or edited in the .reg file in the previous steps.

6. Additionally, use the Certification Authority snap-in to verify the following settings. Right-click the node with the CA name, and click Properties.

   • On the Extensions tab, check all configured CRL distribution point and authority information access extensions for paths that include the host name of the source CA. If the host name of the target CA is different from the host name of the source CA, see Updating CRL Distribution Point and Authority Information Access Extensions and Verifying ACLs on the AIA and CDP Containers, and perform any required steps.

   • If the host name of the target CA is different from the host name of the source CA and you have not yet completed the configuration cleanup steps, perform the steps in Performing Registry Updates after a Host Name Change.

If you choose to import only those registry settings that should be migrated into the target system, the following table shows the configuration parameters that should be transferred from the source CA to the target CA. Any values not listed can retain the value data installed by default with the target CA.

Registry location	Configuration parameter
HKEY_LOCAL_MACHINE\system\currentcontrolset\services\certsvc\Configuration	LDAPFlags
HKEY_LOCAL_MACHINE\system\currentcontrolset\services\certsvc\Configuration\CAname	DSConfigDN ForceTeletex CRLEditFlags CRLFlags InterfaceFlags (required only if has been changed manually) EnforceX500NameLengths SubjectTemplate ValidityPeriod ValidityPeriodUnits KRACertHash KRACertCount KRAFlags CRLPublicationURLs CRLPeriod CRLPeriodUnits CRLOverlapPeriod CRLOverlapUnits CRLDeltaPeriod CRLDeltaPeriodUnits CRLDeltaOverlapPeriod CRLDeltaOverlapUnits CACertPublicationURLs (check for custom entries with hard-coded host names or other data specific to the source CA) CACertHash
HKEY_LOCAL_MACHINE\system\currentcontrolset\services\certsvc\Configuration\CAname\ExitModules\CertificateAuthority_MicrosoftDefault.Exit	PublishCertFlags
HKEY_LOCAL_MACHINE\system\currentcontrolset\services\certsvc\Configuration\CAname\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy	EnableRequestExtensionList EnableEnrolleeRequestExtensionList DisableExtensionList SubjectAltName SubjectAltName2 RequestDisposition EditFlags

Restoring Certificate Template Configuration

After the target CA is installed and the database and registry settings are restored, ensure that an enterprise CA is configured to issue certificates for all the templates for which the source CA was configured. Retrieve the list of templates that was recorded as part of the procedure in Certificate Templates Assigned to an Enterprise CA.

To reassign the templates by using the Certification Authority snap-in

1. Log on with administrative credentials to the target CA computer.

2. Open the Certification Authority snap-in. In the console tree, click Certificate Templates. The details pane contains the list of default certificate templates (unless the CA was customized during or after installation).

3. Right-click Certificate Templates, click New, and then click Certificate Template to Issue.

4. Select the template required, and click OK.

5. Repeat steps 3 and 4 for each required template.

To assign templates from the command line

1. Log on with administrative credentials to the target CA computer.

2. Open a command prompt, and type:

   **certutil –setcatemplates +**templatelist

   Replace templatelist with a comma-delimited list of template short names.

3. Repeat step 3 for each required template.

Although it is possible to set up an enterprise CA on a server running Windows Server 2008 Standard, enterprise features of the CA such as version 2 and version 3 certificate templates are not available. To enable all enterprise CA features, you need to upgrade the server to Windows Server 2008 Enterprise. After the upgrade is complete, you need to complete the following procedure.

To enable the use of version 2 and version 3 certificates on an upgraded enterprise CA

1. Close the Certification Authority snap-in.

2. Open a command prompt window with administrator permissions and run the following script:

   certutil -setreg ca\setupstatus +512

   net stop certsvc

   net start certsvc

3. Use one of the previous procedures to assign the desired certificate templates to the CA.

Resetting the CRL Publishing Period

After completing a migration, restore the CRL and delta CRL publication intervals to their normally required values by using a procedure that is similar to the one described in Publishing a CRL with a Long Validity Period. Once the parameters are reset, ensure that the CA's publishing interval counters are reset and generate an immediate CRL publication by deleting the following registry values:

certutil –delreg CA\CRLNextPublish

certutil –delreg CA\CRLDeltaNextPublish

Restart the CA. The deleted registry values will be reset to use the new settings, and the CRLs will be published immediately.

Verifying Security Settings

At this stage, the CA still has the security settings configured during setup. Even though it is technically possible to migrate the relevant access control settings, it is a better practice to configure the security settings explicitly in the target system and to review them while doing so.

CA Security Settings

To verify the permissions on the CA

1. Log on with administrative credentials to the target CA computer.

2. Open the Certification Authority snap-in.

3. Click the CA object.

4. On the Action menu, click Properties.

5. Click the Security tab.

6. Apply the permissions that have been configured at the source CA or, if changes are required, apply the security settings according to your requirements.

Active Directory Permissions for the CA

Active Directory permissions are required by an enterprise CA for purposes including accessing certificate templates and publishing CA certificates, CRL, and user and computer certificates in AD DS. It is a good practice to verify these permissions after a CA migration, in particular if domain membership has changed. The following list contains all Active Directory permissions required by the computer running the CA.

The required permissions within the Configuration/Services/Public Key Services container are:

• Enrollment Services container

  The CA computer has Read and Write permissions to its own object within the Enrollment Services container.

• AIA container

  • Cert Publishers has Full Control permission on the AIA container.

  • The CA computer has Full Control permission on its own object within the AIA container.

• CDP container

  • Cert Publishers has Full Control permission on each CA's container under the CDP container.

  • The CA computer has Full Control permission on each CRL object in its own container.

• Certification Authorities container

  Cert Publishers has Full Control permission on the objects within this container.

• Certificate Templates container

  Members of Enterprise Admins and Domain Admins, not the CA computer, have Full Control permission or Read and Write permissions to this container and to most objects beneath it. Certificate template ACLs are configured interactively by the CA administrator.

• KRA container

  The CA computer has Full Control permission on its own object within this container.

• OID container

  Members of Enterprise Admins and Domain Admins, not the CA computer, have Full Control permission or Read and Write permission to this container and the containers and objects beneath it.

• NTAuthCertificates object

  Members of Enterprise Admins and Domain Admins, not the CA computer, have Full Control permission or Read and Write permission to this object.

The following permissions are required on Domain Computer and Domain User objects for the CA to publish user or computer certificates:

• Cert Publishers has Read and Write permissions on the userCertificate property of each user and computer object in the forest in which AD CS is deployed.