Performing Post-Upgrade or Post-Migration Tasks

Actualizado: mayo de 2008

Se aplica a: Windows Server 2008

After a migration, you may need to update certain configuration settings to make the target environment consistent. If the migrated certification authority (CA) is an enterprise CA or a stand-alone CA installed by an enterprise administrator on a domain member computer, you may need to update objects in Active Directory® Domain Services (AD DS) that are relevant for Active Directory Certificate Services (AD CS).

In the scenario in which the host name of the target CA is different from the host name of the source CA, the URLs referenced in the authority information access and certificate revocation list (CRL) distribution point extensions of certificates that have already been issued by the source CA may contain references to the old host name. To prevent errors resulting from this, update the configuration of the target CA so that it continues to publish its CRL and CA certificate to the locations referenced by the existing certificates in addition to the locations required by the new CA location.

To update CRL distribution point and authority information access extensions

The exact steps required will vary based on the extensions configured on the source CA. The following steps include the minimum steps required if the source CA had the default extension settings.

Add one new CRL distribution point extension to enable the CA to publish CRLs to the location the original CA included in issued certificates: ldap:///CN=CATruncatedNameCRLNameSuffix,CN=OriginalServerShortName,CN=CDP,CN=Public Key Services,CN=Services,ConfigurationContainerCDPObjectClass.

Replace OriginalServerShortName with the short name of the original CA host.

With the new location highlighted, select the Publish CRLs to this location and Publish Delta CRLs to this location check boxes.

Add any additional authority information access or CRL distribution point extensions required for validation of certificates issued by the original CA. For example, if custom authority information access or CRL distribution point extensions were configured on the source CA to be included in issued certificates, you will need to ensure that those paths resolve to locations where the new CA will publish current CA certificates and CRLs.

Nota

This step is primarily intended for Lightweight Directory Access Protocol (LDAP) paths. An HTTP URL or Universal Naming Convention (UNC) path can also be resolved by using a redirect or another solution.

Click Apply, and click Yes to restart the CA.

Verify the CA can publish CRLs to the new location.

Open the Certification Authority snap-in.

Right-click Revoked Certificates, point to All Tasks, and click Publish.

Click either New CRL or Delta CRL only, and click OK.

Using Adsiedit.msc or other network tools, verify that the CA can publish to the new location.

Verifying ACLs on the AIA and CDP Containers

If the target CA has been modified to publish to the authority information access and CRL distribution point locations of the source CA, perform the following steps to ensure that the CA has the correct permissions to publish to the Active Directory object of the source CA.

To verify ACLs on the AIA and CDP containers

Log on as a user who is a member of the Enterprise Admins group to a computer where the Active Directory Sites and Services snap-in is installed.

Open the Sites and Services snap-in (dssite.msc).

In the console tree, click the top node.

On the View menu, click Show services node.

In the console tree, double-click Services, double-click Public Key Services, and then click AIA.

In the details pane, select the name of the source CA.

On the Action menu, click Properties.

Click the Security tab, and then click Add.

Click Object Types, click Computers, and then click OK.

Type the host name of the target CA, and click OK.

In the Allow column, select Full Control, and click OK.

In the left pane, select CDP and the host name of the source CA.

In the details pane, select the first CRL object.

On the Action menu, click Properties, and then click the Security tab.

In the list of permitted group or user names, select the name of the source CA, click Remove, and then click Add.

Click Object Types, select Computers, and then click OK.

Type the host name of the target CA, and click OK.

In the Allow column, select Full Control, and then click OK.

In the details pane, select the next CRL object, and repeat steps 14 through 18 until you have reached the last object.

Performing Registry Updates after a Host Name Change

If the CA registry configuration settings are migrated from the original server to a target server with a different host name, there are some manual updates that should be made to make the environment consistent. This should be done in addition to any updates to the CA's authority information access and CRL distribution point extension settings.

Perform the following tasks:

Verify that CAServerName is a registry string value located under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\CAName\ registry key. It should be updated to represent the DNS name (for an enterprise CA or domain member CA) or the host name (for a stand-alone workgroup CA) of the new CA host.

Verify that CACertPublicationURLs and CRLPublicationURLs are both registry multi-string values located under the same key as CAServerName. CACertPublicationURLs indicates the authority information access extension settings, and CRLPublicationURLs indicates the CRL distribution point extension settings configured in the Certification Authority snap-in on the CA Properties Extensions tab. While these settings may have been updated as a separate step previously (see Updating CRL Distribution Point and Authority Information Access Extensions), they should be checked in the registry to ensure any hard-coded host names are reconciled with the new environment.

Check the remaining registry values under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc registry key, with emphasis on any values that have been customized to ensure that they are free of data containing the old CA host name or other invalid CA settings. For example:

Configuration\ConfigurationDirectory

Configuration\CAName\CACertFilename

Upgrading Certificate Templates in AD DS

Certificate templates, which are installed in the Certificate Templates container in AD DS and not on the CA itself, may be upgraded at any time after the first installation of, or upgrade to, a Windows Server® 2008–based CA in the forest.

Two new certificate templates are included in AD CS in Windows Server 2008: OCSP Response Signing and Kerberos Authentication. To upgrade certificate templates, after the first CA computer has been upgraded to Windows Server 2008, open the Certificate Templates snap-in as a user who is a member of the Enterprise Admins group.

The template upgrade is required to deploy the Online Responder service, but it is not required for operation of a Windows Server 2008–based CA. If a feature that depends on a Windows Server 2008 template, such as the Online Responder, is required, the template upgrade is required.

Performing a Restore of Encryption Keys

If performing a CA consolidation, you may have to restore previously exported encryption keys to a new CA. In Exporting Archived Encryption Keys (Optional), the certificates and keys have been exported from the CA that originally issued the certificates. After importing the encryption keys into an existing CA, you can remove the CA where the certificates and keys were exported from.

To restore encryption keys into a CA database

Log on with administrative credentials to the existing CA computer.

Open a command prompt.

To allow importing certificates that were issued by a foreign CA, type:

certutil –setreg ca\KRAFlags +KRAF_ENABLEFOREIGN

To activate the new configuration setting, the CA service must be restarted. At a command prompt, type:

net stop certsvc

net start certsvc

If you have not configured recovery agents on the existing CA computer, you have to do so before private keys are imported for archival. The CA must have key recovery agent certificates available to encrypt the private keys. For more information about configuring key archival, see Key Archival and Management in Windows Server 2008 (http://go.microsoft.com/fwlink/?LinkID=92523).