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 |
|
Host name change |
|
CA type change |
|
Domain membership change |
|
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) |
|
In-place upgrade of Windows Server 2003 to Windows Server 2008 |
|
In-place upgrade from Windows Server 2008 Standard to Windows Server 2008 Enterprise |
|
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.
Important
When migrating a CA, the computer name of the target computer can differ from the computer name of the source computer, but the CA name must stay the same.
Note
By default, Active Directory Certificate Services (AD CS) is configured with certificate revocation list (CRL) distribution point extensions that include the CA computer host name in the path. This means any certificates issued by the CA before migration may contain certificate validation paths that contain the old host name. These paths may no longer be valid after the migration. To avoid revocation checking errors, the new CA must be configured to publish CRLs to the old (pre-migration) path as well as the new paths.
The tasks for migrating the CA to a new host are as follows:
Verify that the correct permissions and prerequisites are in place.
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.
Important
Uninstalling the source CA deletes objects from AD DS. If the target CA is a stand-alone CA, then these objects are no longer required. However, if the target CA is an enterprise CA, then it is important to uninstall the source CA before you install the target CA. This ensures the required objects are added to AD DS.
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).
Important
During installation, you must choose to use an existing certificate and private key for the CA, not to create a new CA certificate and key.
- 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.
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.
Note
At this point, if you were to perform a test enrollment, the certificate would be issued from the new CA and contain the CRL distribution point and authority information access extensions you have just configured on the target CA.
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.
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.
Important
A domain controller cannot be removed from a host on which the CA is installed. Therefore, to remove the domain controller, the CA must first be uninstalled from the original host.
The tasks for this option are as follows:
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.
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.
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.
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.
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."
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.
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.
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.
Note
Client computers will not download a more recent CRL until their locally cached CRL expires, so do not set the CRL lifetime to an unreasonably long period.
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
Log on with local administrative credentials to the CA computer.
Click Start, click Run, and type certsrv.msc to open the Certification Authority snap-in.
In the console tree, click the Revoked certificates folder. On the Action menu, click Properties.
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.
.gif)
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.
Click OK.
In the console tree, ensure that Revoked certificates is selected.
On the Action menu, point to All Tasks, and then click Publish.
Make sure that only New CRL is enabled, and click OK.
To verify the CRL publication
Open a command prompt.
At the command prompt, change to the local directory where the CRLs are published. By default, this is %windir%\system32\CertSrv\CertEnroll.
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.
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.
Close the CRL file.
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
Note
If you use an HSM, the CA keys must be backed up by using the backup procedure determined by the HSM vendor.
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
Choose a backup location and attach media, if necessary.
Log on with local administrative credentials to the CA computer.
Open the Certification Authority snap-in.
Right-click the node with the CA name, point to All Tasks, and then click Back Up CA.
On the Welcome page of the CA Backup wizard, click Next.
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.
Note
If you want to back up the CA certificate and private key as a separate step, select only the Certificate database and certificate database log check box.
On the Select a Password page, enter a password to protect the CA private key, and click Next.
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.
Important
After backing up the CA private key, ensure that the key is highly protected to mitigate the possibility of key compromise during this part of the process.
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
Click Start, point to Run, and type regedit to open the Registry Editor.
In HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc, right-click Configuration, and then click Export.
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
Log on with local administrator permissions to the CA computer.
Open the Certification Authority snap-in.
.gif)
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.
Note
If you are performing a CA migration between forests, you must manually re-create all certificate templates in the target Active Directory forest. The only way to create and manage certificate templates is by using the Certificate Templates snap-in.
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
Log on with local administrative credentials to the CA computer.
Open the Certification Authority snap-in.
Select the CA name. On the Action menu, click Properties.
In the CA properties dialog box, click the Certificate Managers Restrictions tab.
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).
Note
A user account owning the correct key recovery agent certificate is required. In addition, Issue permission and Manage Certificates permission are required. Keys are exported into password-protected .pfx files. You must ensure that these files are kept secure and handled appropriately.
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
Log on with local administrative credentials to the CA computer.
Open the Certification Authority snap-in.
In the console tree, select the CA name. On the Action menu, click Properties.
In the CA properties dialog box, click the Security tab.
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.
Click OK, and close the Certification Authority snap-in.
Open a command prompt, and change the path to a working directory.
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.
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.
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.
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.
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.
Note
When the CA is uninstalled, the CA database and the CA certificate, including its private key, remain on the computer. Therefore, if you can reinstall the CA service on the same computer and reuse the existing CA database, certificate, and key.
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
Log on with local administrative credentials to the CA computer.
At a command prompt, type:
certutil -vroot delete
Note
If the Web enrollment role service is accidentally disabled, it can be easily enabled by typing the following command: certutil –vroot.
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.
Note
It is important that you back up the Encrypting File System (EFS) recovery agent private key if you are demoting the first domain controller in the domain.
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
Log on with administrative credentials to the CA computer.
Click Start, click Run, and type dcpromo.
Click Next.
Decide if this is the last domain controller in the domain, and click Next.
Set the password for the local administrator account, and click Next twice.
Click Finish.
Restart the computer.
To demote a Windows Server 2008 domain controller
Log on with administrative credentials to the CA computer.
Click Start, click Run, and type dcpromo.
Click Next.
If the computer is a global catalog server, make sure that other global catalog servers exist in your environment, and click OK.
Decide if this is the last domain controller in the domain, and click Next.
If the computer holds the last copy of directory partitions, click Next to delete them.
If appropriate, accept the deletion of all directory partitions on the domain controller, and click Next.
Remove Domain Name System (DNS) delegations, and click Next.
Set the local administrator password, and click Next.
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
Log on with local administrative credentials to the CA computer.
Click Start, click Run, and type sysdm.cpl to open System properties.
Click the Computer Name tab.
Click Change.
Click Workgroup, enter a workgroup name that is not the same as a domain name in your network, and click OK.
In the Credentials dialog box, click OK.
Click OK three times.
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.
Note
One exception is when upgrading a computer running Windows Server 2003 Standard Edition on which the Microsoft Simple Certificate Enrollment Protocol (MSCEP) from the Windows Server 2003 Resource Kit is installed, to Windows Server 2008 Standard, MSCEP is not upgraded to the Network Device Enrollment Service. This is because the Network Device Enrollment Service is not supported on Windows Server 2008 Standard. It is only supported on Windows Server 2008 Enterprise.
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
Log on with local administrative credentials to the CA computer.
Click Start, click Run, and type sysdm.cpl to open System properties.
Click the Computer Name tab.
Click Change.
Click Domain, type the domain name, and then click OK.
Type the credentials that have permissions to join a computer to the domain, and click OK.
Click OK three times.
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
Log on with local or enterprise administrator permissions to the CA computer.
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).
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.
Select the CA type, select the Use custom settings to generate the key pair and CA certificate check box, and then click Next.
Important
If the source CA was a root CA, the target CA must also be a root CA, though it can be either enterprise or stand-alone. If the source CA was a subordinate CA, the target CA must also be a subordinate CA.
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.
Select the CSP and hash algorithm that you noted in the "Performing a CA Backup" procedure, and click Next.
Important
The CSP must match the CSP that was used to generate the key on the source CA. If the CA key was generated with a CSP that is available with Windows, no further steps are required. Otherwise, the CSP must be installed on the target CA before the CA is installed.
If the CA is installed on a workgroup computer, optionally set the distinguished name suffix, and click Next.
Specify the certificate database, 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.
Once the installation has ended, click Finish.
Click Close, and restart the computer.
Windows Server 2008
To set up a CA on a computer running Windows Server 2008
Log on with local or enterprise administrator permissions to the CA computer.
Click Start, click Run, type servermanager.msc, and then press ENTER to open Server Manager.
In the console tree, click Roles.
On the Action menu, click Add Roles.
If the Before you Begin wizard appears, click Next.
In the list of available server roles, select the Active Directory Certificate Services check box, and click Next twice.
Make sure that Certification Authority is selected, and click Next.
Choose if you are migrating to an enterprise or stand-alone CA, and click Next.
Specify either Root or Subordinate CA, depending on the source CA, and click Next.
Important
If the source CA was a root CA, the target CA must also be a root CA, though it can be either enterprise or stand-alone. If the source CA was a subordinate CA, the target CA must also be a subordinate CA.
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.
.gif)
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.
Note
The Use strong private key protection feature provided by the CSP option is only relevant if a custom CSP is used. None of the CSPs available with Windows requires this option to be selected. On the Select Certificate page, click Next.
- 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
Log on with administrative credentials to the target CA computer.
Open the Certification Authority snap-in.
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.
In the CA Restore wizard, on the Welcome page, click Next.
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.
Note
Make sure you select the folder above the Database folder, or the wizard will fail to locate the files to restore.
Enter the password you used to export the CA database from the source CA, if a password is requested.
Click Finish, and then click Yes to confirm restarting the CA.
Note
At this point, the new CA should be online and functional. You can test this by sending a new enrollment request (by using the Certificate Request Wizard or Certreq.exe, depending on the CA type) and verifying that it was successfully processed by the new CA. You can then decide whether to import the registry settings from the old CA or apply them manually.
To restore the CA database by using the command line
At a command prompt, type certutil -shutdown to shut down the CA service.
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.
Note
The command output shows three locations: the CA database, the CA database log, and a database checkpoint file, which is not used by the CA.
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.
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.
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.
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.
Important
Some registry parameters should be migrated without changes from the source CA computer, and some should not be migrated. If they are migrated, they should be updated in the target system after migration because some values are associated with the CA itself, whereas others are associated with the domain environment, the physical host, the Windows version, or other factors that may be different in the target system.
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
Right-click the .reg file created by exporting the settings from the source CA.
Click Edit to open the file in a text editor.
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.
Important
If the host name is located in the .reg file as part of the CA name, such as in the Active value within the Configuration key or the CommonName value within the CAName key, do not change the setting. The CA name must not be changed as part of the migration. This means the new target CA must have the old CA's name, even if part of that name is the old CA's host name.
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
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
On the target CA, use the Certification Authority snap-in to stop the CA service.
Double-click the .reg file previously edited to open the Registry Editor.
Confirm that the registry keys were imported, and close the Registry Editor.
Restart the CA.
Use the Registry Editor to verify any settings that were changed or edited in the .reg file in the previous steps.
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
Log on with administrative credentials to the target CA computer.
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).
Right-click Certificate Templates, click New, and then click Certificate Template to Issue.
Select the template required, and click OK.
Repeat steps 3 and 4 for each required template.
To assign templates from the command line
Log on with administrative credentials to the target CA computer.
Open a command prompt, and type:
**certutil –setcatemplates +**templatelist
Replace templatelist with a comma-delimited list of template short names.
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
Close the Certification Authority snap-in.
Open a command prompt window with administrator permissions and run the following script:
certutil -setreg ca\setupstatus +512
net stop certsvc
net start certsvc
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
Log on with administrative credentials to the target CA computer.
Open the Certification Authority snap-in.
Click the CA object.
On the Action menu, click Properties.
Click the Security tab.
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.
Note
Some permissions are achieved via membership in the Cert Publishers group. After a CA migration, check this group to ensure that the new CA computer is a member.
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.