Planning the Upgrade or Migration
Applies To: Windows Server 2008
Organizations have different reasons and requirements for upgrading or migrating to Active Directory® Certificate Services (AD CS). They include:
An existing, properly implemented, and operating public key infrastructure (PKI) may require an upgrade to a newer Windows® version to make use of new features.
Organizations may need to change or optimize their existing PKI. For example, the certification authority (CA) may have been installed on a domain controller, or incorrect configuration options may have been selected. To change the AD CS implementation so that it follows deployment best practices requires migration. In these cases, upgrading is optional and can be performed after the migration has been completed successfully.
Microsoft defines and publishes a support lifecycle for each of its products. We recommend upgrading to a newer product before the support lifecycle of a product has ended. For example, CAs running on the Microsoft Windows 2000 Server operating system should be upgraded to Windows Server® 2003 to be supported and can then be upgraded to Windows Server 2008.
Company mergers and reorganizations are a challenge for information technology (IT) departments and can be especially challenging for the PKI deployment. A PKI can be affected if organizational changes require naming changes or consolidation, or when encrypted information must be transferred to a new owner and encryption certificates be made available to the new owner.
This topic discusses various requirements you need to consider when planning your AD CS upgrade or migration, including determining whether to migrate or upgrade, identifying hardware and software requirements, and planning a phased upgrade.
Determining Whether to Upgrade or Migrate
The choice between whether to upgrade or migrate your AD CS environment depends on the features and role services you want to implement and the current and desired network environment that you want to create. The following sections will help you understand and select the appropriate options and strategies for your organization.
When to Upgrade
An upgrade is a straightforward, in-place task. Because AD CS is part of the Windows operating system (included as an optional component in Windows Server 2003 and as one of the server roles in Windows Server 2008), you only need to upgrade the operating system to upgrade the CA or any other AD CS component. For example, upgrade scenarios include:
Upgrade a Windows 2000 Server–based CA to Windows Server 2003.
Upgrade a Windows Server 2003–based CA to Windows Server 2008.
Upgrade an enterprise CA running a Standard edition of Windows Server to an Enterprise edition of Windows Server. (This upgrade is required if you want to use extended features such as certificate autoenrollment.)
One exception to this upgrade definition is the scenario in which a stand-alone CA is changed to an enterprise CA. Because this is a change of the CA type and not of the operating system version or edition, this is not considered a Windows upgrade and does not require a new Windows license, provided that the stand-alone CA is already running on a fully licensed installation of Windows Server. In this scenario, migration would be required. For information about migration, see When to Migrate.
An upgrade is required primarily when you want to use a new operating system, have access to new AD CS features, or maintain a supported environment.
Before deciding to upgrade, it is important to understand which of the available services and features that you require so you can deploy the correct infrastructure and implement the proper upgrade procedures to support them.
AD CS Features in Windows Server 2003 and Windows Server 2008
Important AD CS features to consider in Windows Server 2003 and Windows Server 2008 include the following:
Certificate templates. Certificate templates were introduced with Certificate Services in Windows 2000 Server. These version 1 certificate templates could not be modified, with the exception of permissions, and did not support autoenrollment. In Windows Server 2003, version 2 certificate templates were introduced and required a server running Windows Server 2003 Enterprise Edition. Version 2 templates could be modified by using the Certificate Templates Microsoft Management Console (MMC) snap-in and offered support for autoenrollment. In Windows Server 2008 Enterprise, version 3 certificate templates add support for Cryptography Next Generation (CNG) and require client computers that are running Windows Vista®.
Automatic key archival. Key archival is highly recommended if encryption certificates are issued. Without the ability to recover encryption certificates, organizations can lose data if the owner of an encryption certificate loses the private key that is associated with the certificate. Automatic key archival was introduced in Windows Server 2003 Enterprise Edition.
Autoenrollment. If Active Directory Domain Services (AD DS) is available, certificate autoenrollment can provide a very efficient way to enroll certificates for large numbers of users and devices. Users and computers can receive and renew certificates automatically based on their Windows authentication. Autoenrollment for computer certificates was introduced in Windows 2000 Server and was extended to all types of certificates in Windows Server 2003 Enterprise Edition. Autoenrollment requires version 2 or 3 templates and, therefore, requires an enterprise CA installed on a computer running Windows Server 2008 Enterprise or Windows Server 2003 Enterprise Edition.
Web enrollment. Support to enroll certificates manually from a Web interface has existed since Windows 2000 Server. This support continues in Windows Server 2003 and Windows Server 2008. Web enrollment support provides the same features on all supported Windows Server 2008 versions, regardless of CA type. However, there are functionality changes to Web enrollment in Windows Server 2008 versus Windows Server 2003. For more information, see Web Enrollment Changes.
CRL publishing to AD DS. If installed on a domain member, a Windows-based CA can publish its certificate revocation list (CRL) to AD DS automatically. CRL publishing to AD DS requires a stand-alone CA or a CA installed on a computer running Windows Server 2008 Standard or Windows Server 2003 Standard Edition. Domain membership is required because authentication is required to perform write operations on Active Directory objects.
Role separation. Role separation is a feature that was introduced in Windows Server 2003 for Common Criteria EAL4+ certification. When enabled, role separation enforces that a user with more than one CA role cannot perform any CA operation. Without enabling role separation, a single user can be assigned multiple CA roles. Role separation requires Windows Server 2008 Enterprise or Windows Server 2003 Enterprise Edition.
New AD CS Features in Windows Server 2008
New AD CS features in Windows Server 2008 include the following:
CNG support, including support for Suite B encryption algorithms. This feature is available for all CA types on all Windows Server 2008 versions but can be used only by client computers running Windows Server 2008 or Windows Vista. For more information about CNG, see CNG Features (https://go.microsoft.com/fwlink/?LinkId=117334).
Failover clustering for the CA. A new feature of Windows Server 2008 is the ability to set up AD CS on a two-node Windows cluster that has an active/passive configuration.
Restricted certificate enrollment agents. The restricted enrollment agent is a new CA feature in Windows Server 2008 Enterprise. It allows limiting the permissions that users designated as enrollment agents have for enrolling certificates on behalf of other users.
Online Responder service to support OCSP for revocation checking. The Online Certificate Status Protocol (OCSP) is an HTTP-based protocol that allows a relying party to submit a certificate status request to an OCSP responder, which returns a definitive, digitally signed response indicating the certificate status. The amount of data retrieved per request is constant regardless of the number of revoked certificates on the CA. The Online Responder in Windows Server 2008 is able to provide responses to OCSP requests for certificates issued by a CA on a computer running Windows Server 2008 or Windows Server 2003. The Online Responder itself, however, can be installed only on a computer running Windows Server 2008 Enterprise. For more information about the Online Responder, see Installing, Configuring, and Troubleshooting the Online Responder (https://go.microsoft.com/fwlink/?LinkId=101269).
Network Device Enrollment Service enhancements. The Network Device Enrollment Service is the Windows Server 2008 role service that implements the Simple Certificate Enrollment Protocol (SCEP). The Network Device Enrollment Service is supported only on Windows Server 2008 Enterprise but can be installed on a different computer from the CA it works with. For more information, see Installing, Configuring, and Troubleshooting the Network Device Enrollment Service (https://go.microsoft.com/fwlink/?LinkID=93875).
In addition, the following enhancements to AD CS in Windows Server 2008 can also be factors in an upgrade decision:
Database performance improvements for AD CS
Performance counters for the CA and the Online Responder
Integration with Microsoft Operations Manager (MOM) 2005 and Microsoft System Center Operations Manager 2007
Note
For additional information about the new features and enhancements in AD CS in Windows Server 2008, see Active Directory Certificate Services (https://go.microsoft.com/fwlink/?LinkId=104436).
CA Features
Some role services and features are only available on certain editions of Windows Server 2003 and Windows Server 2008. Therefore, as part of upgrade planning, review the following information to ensure that your plans include the correct Windows edition for the features you require.
The following table shows the features supported by the Standard edition of Windows Server 2003 and Windows Server 2008.
CA features supported in Windows Server 2008 Standard or Windows Server 2003 Standard Edition
| Features | Stand-alone CA on a workgroup computer | Stand-alone CA on a domain member | Enterprise CA on a domain member |
|---|---|---|---|
Certificate templates |
No |
No |
Version 1 templates only |
CNG support |
Windows Server 2003: No Windows Server 2008: Yes, for CA certificates and manually created certificate requests |
Windows Server 2003: No Windows Server 2008: Yes, for CA certificates and manually created certificate requests |
Windows Server 2003: No Windows Server 2008: Yes, for CA certificates and manually created certificate requests only; autoenrollment with CNG requires version 3 templates |
CRL publishing to AD DS |
No |
Yes |
Yes |
Web enrollment |
Yes |
Yes |
Yes |
Network Device Enrollment Service |
Windows Server 2003: Yes, with the Microsoft SCEP (MSCEP) tool that is available with the Windows Server 2003 Resource Kit Windows Server 2008: No |
Windows Server 2003: Yes, with MSCEP Windows Server 2008: No |
Windows Server 2003: Yes, with MSCEP Windows Server 2008: No |
The following table shows features supported by Enterprise and Datacenter editions of Windows Server 2003 and Windows Server 2008.
CA features in Windows Server 2008 Enterprise, Windows Server 2003 Enterprise Edition, Windows Server 2008 Datacenter, and Windows Server 2003 Datacenter Edition
| Features | Stand-alone CA on a workgroup computer | Stand-alone CA on a domain member | Enterprise CA on a domain member |
|---|---|---|---|
Certificate templates |
No |
No |
Windows Server 2003: Version 1 and version 2 templates Windows Server 2008: Version 1, version 2, and version 3 templates |
CNG support |
Windows Server 2003: No Windows Server 2008: Yes, for CA certificates and manually created certificate requests only |
Windows Server 2003: No Windows Server 2008: Yes, for CA certificates and manually created certificate requests only |
Windows Server 2003: No Windows Server 2008: Yes, for CA certificates, manually created certificate requests, and autoenrollment (requires version 3 templates) |
Automatic key archival |
No |
No |
Yes |
Autoenrollment |
No |
No |
Yes |
Restricted enrollment agents |
No |
No |
Windows Server 2003: No Windows Server 2008: Yes |
CRL publishing to AD DS |
No |
Yes |
Yes |
Role separation |
Yes |
Yes |
Yes |
Failover clustering support |
Windows Server 2003: No Windows Server 2008: Yes |
Windows Server 2003: No Windows Server 2008: Yes |
Windows Server 2003: No Windows Server 2008: Yes |
Web enrollment |
Yes |
Yes |
Yes |
Online Responder |
Windows Server 2003: No Windows Server 2008: Yes |
Windows Server 2003: No Windows Server 2008: Yes |
Windows Server 2003: No Windows Server 2008: Yes |
Network Device Enrollment Service |
Windows Server 2003: Yes, with MSCEP Windows Server 2008: Yes |
Windows Server 2003: Yes, with MSCEP Windows Server 2008: Yes |
Windows Server 2003: Yes, with MSCEP Windows Server 2008: Yes |
Combining and Distributing Role Services
CAs, Web enrollment, the Online Responder, and the Network Device Enrollment Service can all be installed on the same computer, or in any combination of role services. The recommended number of servers and the level of service distribution, therefore, depend on security and availability requirements.
Each AD CS role service can be deployed on one or more servers to meet service requirements. For the CA, this means deploying multiple CAs and, optionally, deploying individual CAs on failover clusters that have an active/passive configuration. For the Online Responder, this means deploying multiple-node clusters of Online Responders that are load balanced by using Network Load Balancing (NLB).
When to Migrate
Migration may be performed as part of a PKI upgrade, or it can be used to apply configuration changes to an existing Windows–based PKI without upgrading the operating system version.
Migration can accomplish changes to the CA environment, configuration, or deployment architecture that cannot be performed in place. While preserving CA identity, functionality, and transaction history, the existing data and configuration is exported from the existing environment and moved to a new environment that has different characteristics.
The following scenarios each require a CA migration:
The server on which a CA service is installed needs to become a domain member, be removed from a domain, or moved to a different domain. In this white paper, this scenario is described as a domain membership change.
If a CA service was installed on a domain controller, it is a good practice to transfer the CA to a dedicated server. In this case, a domain role change would apply.
If the host name of a server on which a CA is installed must be changed, a migration is required. This is called a migration with host name change.
If newer hardware can provide improved performance, such as a 64-bit CPU, the CA component needs to be removed from the old hardware and moved to the new hardware. This called a hardware change.
Also, moving two enterprise CAs into a clustered CA is similar to a hardware change.
To increase the functionality of a CA, it is a common requirement to turn a stand-alone CA into an enterprise CA. It is sometimes, though rarely, a necessity to turn an enterprise CA into a stand-alone CA. Both scenarios are described as a CA type change.
Note
Note the distinction between a CA type change and a Windows edition change. While named similarly, an enterprise CA is different from a CA installed on an Enterprise edition of Windows Server. The former is a CA type (specifically the type of CA that can support templates), and the latter refers to a CA of either type (enterprise or stand-alone) that is installed on an Enterprise edition of Windows Server.
An important decision in planning is to choose specifically what elements of the domain and forest environment to change, and in what order. At this stage, upgrade or migration of Certificate Services may be combined with other IT and business initiatives such as domain consolidation, virtualization, and hardware upgrade, or even implementation of new application scenarios.
Supported migrations
| CA migration scenario | Windows Server 2008 (no change in operating system) | From Windows Server 2003 to Windows Server 2008 | Notes | |
|---|---|---|---|---|
|
Stand-alone CA to enterprise CA |
Yes |
Yes |
||
|
Enterprise CA to stand-alone CA |
Yes |
Yes |
To remove Active Directory information, uninstall the enterprise CA on the source computer. |
|
|
x86 to x64 |
Yes |
Yes |
||
|
Computer to computer with host name change |
Yes |
Yes |
The CA name must stay the same. |
|
|
Physical computer to virtual machine |
Yes |
Yes |
Tested with Microsoft Virtual Server 2005. |
|
|
Domain to domain (within the same forest) |
Yes |
Yes |
Verify the Cert Publishers group membership after migration. |
|
|
Single computer to cluster |
Yes |
Yes |
||
|
CA name change |
No |
No |
A host name change is supported, but the CA name must stay the same. |
|
|
Root CA to subordinate CA |
No |
No |
A CA certificate from a root CA cannot be used for a subordinate CA. |
|
|
Subordinate CA to root CA |
No |
No |
A CA certificate from a subordinate CA cannot be used for a root CA. |
|
|
Forest-to-forest migration |
No |
No |
Requires redeployment in the new forest. |
|
|
Migration with language change |
No |
No |
||
The number of tasks involved in a migration depends on the scenario. If more configuration parameters are changed, more migration tasks might need to be performed. In all cases, migrations include a CA backup and restore procedure. The process is as follows:
Back up the source CA (CA database, certificate, and keys).
Back up the source CA configuration (registry configuration, templates, and other settings).
Install the CA on the target computer, using the existing certificate and key.
Restore the CA database on the target CA.
Import the CA configuration on the target CA.
Complete post-migration tasks.
Performing other tasks such as a Windows upgrade or CA configuration changes depends on the migration scenario.
Combining Migration and Upgrade
Migration and upgrade can be combined to apply important configuration changes or to simplify the upgrade. For example, hardware changes might be necessary if you plan to upgrade to Windows Server 2008. In this case, you could first migrate the CA to the new hardware and then perform the in-place upgrade. However, it may be easier to migrate the CA directly from the server running Windows Server 2003 to a server running Windows Server 2008. For details about the procedure, see "Hardware change" under Tasks Required for Key CA Upgrade and Migration Scenarios.
Moving a Windows Server 2003–based CA from a domain controller is a combined scenario, in which migration is the first step, followed (optionally) by an upgrade to Windows Server 2008. If you separate the CA and domain controller role before the Windows upgrade, you will not need to upgrade your domain controller with the CA upgrade.
Identifying Hardware and Software Requirements
The next step is to verify that you have the correct hardware and software to support the services you need.
Requirements for AD CS
The requirements described in this section apply to all AD CS role services available in Windows Server 2008: CA, Web Enrollment, Online Responder, and the Network Device Enrollment Service.
Hardware Requirements
The hardware requirements to install any of the AD CS role services are the same as the minimum and recommended configurations for installation of Windows Server 2008. This section includes the general hardware recommendations for Windows Server 2008. For detailed requirements, see Windows Server 2008 System Requirements (https://go.microsoft.com/fwlink/?LinkId=117345).
Important
The performance of AD CS can be constrained by CPU power and hard disk speed. A recommended hard disk speed is 10,000 RPM or faster; processor power is more important than memory capacity. The required disk space depends strongly on the number of certificates that will be issued from that CA and whether key archival is used. Generally, a single certificate can be estimated as requiring 64 KB of database space.
Hardware requirements for AD CS in Windows Server 2008
| Hardware | Minimum | Recommended |
|---|---|---|
Memory |
512 MB |
2 GB or more |
Processor |
1 GHz (for x86 processors) or 1.4 GHz (for x64 processors) |
2 GHz or faster |
Disk space |
10 GB |
Depends on the number of issued certificates |
Network |
100 megabit |
1 gigabit |
Also consider the following when assessing your hardware needs for an AD CS upgrade:
AD CS is not supported on Itanium-based computers. Itanium is the brand name for 64-bit Intel microprocessors that implement the Intel Itanium architecture.
The approximate disk space requirements for AD CS depend on the number of issued certificates. Because the CA stores the request, the certificate, and, optionally, the archived key material, 64 KB of database space per submission is recommended.
For the system, the CA database, and the log files to be stored on different physical disk drives, a multi-disk configuration for computers running AD CS is recommended. For optimal performance and reliability of the CA, consider a redundant array of independent disks (RAID) system, such as RAID 5 for the database and log files and RAID 1 or RAID 0+1 for the system.
Software Requirements
AD CS in Windows Server 2008 can be installed on a computer running Windows Server 2008 Standard, Windows Server 2008 Enterprise, or Windows Server 2008 Datacenter.
When AD CS is installed in an AD DS domain on a computer running Windows Server 2008 or Windows Server 2003, the AD DS schema version must be at least 30 and all domain controllers in the domain must be running one of the following operating systems:
Windows Server 2008 with Service Pack 1 (SP1)
Windows Server 2008
Windows Server 2003 R2
Windows Server 2003 with Service Pack 2 (SP2)
Windows Server 2003 with SP1
Windows Server 2003
Note
While domain controllers running Windows 2000 Server with Service Pack 4 (SP4) and Windows 2000 Server with Service Pack 3 (SP3) are technically compatible with AD CS deployments, the use of Windows 2000 Server is not recommended because Mainstream Support is no longer available for this operating system. For more information, see Microsoft Support Lifecycle (https://go.microsoft.com/fwlink/?LinkId=117347).
The Online Responder and Network Device Enrollment Service require the Web Server (IIS) server role and the Windows Process Activation Service (WAS). These features will be installed automatically during the Online Responder or Network Device Enrollment Service installation. For more information about WAS, see WAS Activation Architecture (https://go.microsoft.com/fwlink/?LinkID=100709).
Supported Upgrade Paths
The previous sections list requirements for installation of AD CS role services. Upgrading an earlier version of Certificate Services to AD CS introduces some additional requirements that are described here.
The following are supported in-place upgrade paths:
- From Windows Server 2003 Standard Edition to Windows Server 2008 Standard or Windows Server 2008 Enterprise
Note
When upgrading a computer running Windows Server 2003 Standard Edition, on which MSCEP from the Windows Server 2003 Resource Kit is installed, to Windows Server 2008 Standard, Network Device Enrollment Service will not be upgraded. Network Device Enrollment Service is not supported on Windows Server 2008 Standard.
From Windows Server 2003 Enterprise Edition to Windows Server 2008 Enterprise
From Windows Server 2003 Datacenter Edition to Windows Server 2008 Datacenter
Important
Before upgrading to AD CS, the CA must first be upgraded to Windows Server 2003 R2, Windows Server 2003 with SP1, or Windows Server 2003 with SP2. Upgrading from a Windows 2000 Server–based CA to Windows Server 2008 is not supported.
Client Requirements
The following sections describe the AD CS changes that affect a client computer.
The requirements that a client computer must fulfill to support autoenrollment, Web enrollment, or manual enrollment are the same for a CA installed on a computer running either Windows Server 2008 or Windows Server 2003. Client computers with the most recent service packs of Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008, including Server Core installations, can enroll for certificates from a Windows Server 2008–based CA by using autoenrollment, manual enrollment, or Web enrollment.
There are, however, some special considerations for Web enrollment and for OCSP.
Web Enrollment Changes
The following list of changes applies to the Web enrollment pages installed on a computer running Windows Server 2008.
New enrollment application programming interface (API)
Windows Vista introduced a new enrollment API called CertEnroll to replace the Xenroll and SCardEnroll APIs that were available in Windows XP, Windows Server 2003, and earlier operating systems. However, the Windows Server 2003 Web enrollment pages require Xenroll; they will not work with client computers running Windows Vista. The Windows Server 2008 Web enrollment pages support certificate enrollment from client computers by using either Xenroll or CertEnroll. To enable Web enrollment from any Windows client version, upgrade Web enrollment pages to Windows Server 2008. For information about installing Windows Server 2008 Web enrollment pages without upgrading Web enrollment servers, see article 922706 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkID=85331).
Computer certificates
Beginning with the Windows Server 2008 Web enrollment pages, users can no longer use Web enrollment to request computer certificates, regardless of the client operating system. This change was implemented for security reasons and affects client computers running Windows XP or Windows Vista.
Secure Sockets Layer (SSL) requirement
A client computer running Windows Vista or Windows Server 2008 must establish an SSL connection with a Windows Server 2008–based computer running Web enrollment pages when requesting a certificate or submitting a certificate request. Certificate submission and enrollment will fail if an HTTP connection is used instead. In addition, the URL referring to the Web enrollment pages must be part of the trusted sites in the client's Windows Internet Explorer® configuration.
Support for non-text browsers
Because of the enhancements in Web enrollment pages for Windows Server 2008, it is no longer possible to use text browsers.
Changes to functionality of enrollment on behalf of a user
Web enrollment support in Windows Server 2003 has the capability to enroll smart cards on behalf of a user. This functionality is now also available as part of the Certificates snap-in in Windows Vista and Windows Server 2008. Therefore, it has been deprecated in the Web enrollment pages available in Windows Server 2008.
Save to file
For security reasons, the Web enrollment pages do not save certificate requests and responses to files but display them on the screen instead. The user must copy the text and paste it into a file.
Online Responder Client
Consider the following for the OCSP client:
To use the Online Responder capabilities of Windows Server 2008, the client computer must have an OCSP client.
An OCSP client is included in Windows Vista and Windows Server 2008.
Client computers running Windows versions earlier than Windows Vista must use non-Microsoft OCSP client software to send OCSP requests to the Online Responder.
CA Clustering Requirements
Windows Server 2008 Enterprise and Windows Server 2008 Datacenter support failover clustering for the CA. Clustering can mitigate hardware failures because a single CA instance is configured to run virtually on two physical cluster nodes.
To run a CA on a Windows Server 2008–based failover cluster, the following prerequisites must be met:
Clustering is only supported for the CA service and not the CA Web enrollment service, OCSP service, or Network Device Enrollment Service.
Clustering can be configured on a two-node cluster. More than two nodes for an AD CS cluster is not supported.
The cluster is configured as an active/passive cluster. CA clusters configured as active/active are not supported.
The CA database and the log files must be stored in a location that is available to both cluster nodes.
Planning a Phased Upgrade
If there is no immediate need to upgrade all servers to Windows Server 2008, the upgrade and migration project can be performed in phases over a longer period of time. At the completion of each phase, the environment will include both Windows Server 2003 and Windows Server 2008 components. For example, an issuing CA may be upgraded to Windows Server 2008 while its offline root remains at the Windows Server 2003 functional level. Alternatively, some issuing CAs in the environment may remain at the Windows Server 2003 functional level while others are upgraded. Ensure that you note the exceptions described in the following tables.
CA mixed scenarios
| Scenario | Notes |
|---|---|
Windows Server 2003–based root CA with a Windows Server 2008–based subordinate CA Or Windows Server 2003–based subordinate CA under a Windows Server 2008–based root CA |
Because the CA must be able to verify its own certificate chain, configuring a Windows Server 2008–based CA for CNG requires all CAs in the chain to be upgraded to Windows Server 2008. |
Windows Server 2003 and Windows Server 2008 issuing CAs in the same forest |
Because restrictions on enrollment agents cannot be enforced on a Windows Server 2003–based CA, ensure the templates that enrollment agents can use are assigned only to Windows Server 2008–based CAs. |
Web enrollment mixed scenarios
| Scenario | Notes | |
|---|---|---|
|
Windows Server 2008–based CA with Windows Server 2003 Web enrollment |
Note the issues described in Web Enrollment Changes. |
|
|
Windows Server 2003–based CA with Windows Server 2008 Web enrollment |
Note the issues described in Web Enrollment Changes. |
|
Online Responder mixed scenario
| Scenario | Notes |
|---|---|
Windows Server 2003–based CA with an Online Responder in Windows Server 2008 |
The Online Responder in Windows Server 2008 can provide certificate verification responses for certificates issued by Windows Server 2003–based CAs and Windows Server 2008–based CAs. Manual steps are required to configure a Windows Server 2003–based CA to work with an Online Responder. A Windows Server 2003 certificate template for issuing OCSP signing certificates needs to be created and assigned to any Windows Server 2003–based CA. The Windows Server 2003–based CA configuration must be changed to allow the custom extension required for OCSP. The Windows Server 2003–based CA must be configured to include the OCSP URL in certificates it issues. The Windows Server 2003–based CA configuration can also be changed to accept certificate requests with an authority key identifier extension. This helps the CA issue OCSP signing certificates in certain scenarios after the CA signing certificate is renewed. For more information about the configuration of the Online Responder, see "Preparing the Environment" in Installing, Configuring, and Troubleshooting the Online Responder (https://go.microsoft.com/fwlink/?LinkID=101269). |
Network Device Enrollment Service mixed scenarios
| Scenario | Notes |
|---|---|
Windows Server 2003–based CA with the Network Device Enrollment Service in Windows Server 2008 |
Whereas MSCEP is supported on both Windows Server 2003 Standard Edition and Windows Server 2003 Enterprise Edition, the Network Device Enrollment Service is only available on Windows Server 2008 Enterprise. If the Network Device Enrollment Service is configured to work with a stand-alone CA, the stand-alone CA and the Network Device Enrollment Service must be on the same computer. Therefore, the Network Device Enrollment Service cannot be configured to work with a remote Windows Server 2003–based stand-alone CA. The Network Device Enrollment Service can be configured to work with a Windows Server 2003–based enterprise CA on a different computer. |
Windows Server 2008–based CA with MSCEP in Windows Server 2003 |
This scenario is not supported because MSCEP must run on the same computer as the CA, and MSCEP is not supported on Windows Server 2008. |
When deciding how to start the upgrade, first determine if you want to implement features that have few prerequisites first, or whether to focus on features that will involve more prerequisites. In general, you should upgrade optional PKI components first, before upgrading the CAs. This approach has two advantages. One is that upgrading the Web enrollment and the Network Device Enrollment Service components is straightforward and can be rolled back quickly if required. Second, the new components are backward-compatible, with the restrictions highlighted in the previous tables.
Tasks Required for Key CA Upgrade and Migration Scenarios
The upgrade or migration of an enterprise CA can entail many different tasks. The following figure illustrates the general workflow, while detailed step-by-step procedures are provided in Performing the Upgrade or Migration.
.gif)
The primary tasks for upgrade and migration for key scenarios are as follows:
Hardware change
With the availability of Windows Server 2008, many organizations want to migrate their infrastructure to upgraded x64-based servers to make use of virtualized infrastructure or to make other hardware changes.
Migrating a CA to different hardware, physical or virtual, is the simplest migration scenario. It consists of the following major steps:
CA backup (CA database, certificate, and keys) from the source CA
CA configuration backup (registry configuration, templates, and other settings) from the source CA
CA installation on the target system with the same host name and CA type, using the existing certificate and key
CA database restore on the target CA
CA configuration import on the target CA and templates reassignment to the CA
Domain role change
Organizations may need to move a CA from a domain controller or other multipurpose server to a dedicated server. Separating the CA from other services is recommended to enhance the overall defense against attacks.
To move an enterprise issuing CA to a different server is very similar to the previous simple migration scenario. There is an additional step to reconcile the dependencies between the CA and the domain controller on the source computer. Two options for performing this type of migration are described in Example: Moving a CA from a Domain Controller.
CA type change
Changing the CA type from a stand-alone to an enterprise CA may be required to expand the PKI to support thousands of users and computers, or to benefit from all features of an enterprise CA. The steps required to migrate an enterprise to a stand-alone CA, or vice versa, are the same as the simple hardware change documented previously. The target CA can be installed as either of these CA types, regardless of the type of the source CA. Note that if key archival was used on a source enterprise CA, archived keys will be recoverable from the stand-alone target CA, but new keys cannot be archived. Also note that if an enterprise CA is migrated to a stand-alone CA, it is important to uninstall the source CA after the migration. This removes unnecessary information from AD DS.
Domain membership or host name change
An enterprise issuing CA can only be installed on a computer that is a domain member. As part of a domain consolidation, acquisition or reorganization, or server relocation, it may be required to change the domain membership of the computer running the CA.
Similarly, it is a common requirement to change the host name of a CA, if it is not compliant with new organizational naming conventions. Because the existence of the CA service on a Windows–based server prohibits any host name or domain name changes, this scenario requires a migration consisting of the following major tasks. This scenario is described in Option A: Migrate the CA to a New Host.
Change the Windows Server edition from Standard edition to Enterprise edition
An enterprise CA can be installed on a Standard edition of Windows Server, but it will lack certain features such as version 2 certificate template support and autoenrollment, which are available on the Enterprise edition. Changing the Windows Server edition from Standard to Enterprise edition provides all features of an enterprise CA.
Upgrading from the Standard edition of Windows Server to the Enterprise edition is a straightforward task and does not require migration. The operating system is upgraded, and the CA configuration and database are preserved. After the upgrade, an enterprise CA can use the new features that are supported only on the Enterprise edition of Windows Server.
Note
Changing the Windows Server edition requires a new license for the Windows Server edition.
Migrate to a CA failover cluster
A new feature of Windows Server 2008 is failover clustering for the CA. You might need to migrate an existing enterprise issuing CA into a CA cluster. This scenario is similar to the hardware change scenario, but it requires a CA failover cluster running on Windows Server 2008 Enterprise as the target environment. For more information about installing and configuring a CA in a failover cluster, see Configuring Active Directory Certificate Services Failover Clustering (https://go.microsoft.com/fwlink/?LinkId=116453).
Forest-to-forest migration
AD CS is a forest resource and can support only users or groups from within the forest. Once a CA is moved into a new forest, existing users from the old forest cannot access AD CS. If the CA will be moved to a new forest, the CA must be redeployed and all certificates reissued.
Intermediate and Root CAs
During your planning phase, you should consider the following information about intermediate and root CAs:
You should consider upgrading intermediate and root CAs if the operating system used by the CA is no longer supported. This is not a task that needs to be performed immediately, but it is still an important task.
When you upgrade any CA, especially an offline root CA, ensure that you can finish the upgrade before any CRLs issued by that CA expire.
Intermediate and root CAs should be run on a Standard edition of Windows Server as stand-alone CAs so that they can be disconnected from the network.
If a hardware security module (HSM) is used, contact the HSM vendor before starting the CA upgrade to determine if the HSM cryptographic service provider (CSP) or key service provider (KSP) that the HSM is using will support the Windows version that is installed.
The upgrade and migration steps for an intermediate or root CA are the same as for an issuing CA.
Web Enrollment Pages Upgrade and Migration
Planning the upgrade of Web enrollment pages provides a good opportunity to reevaluate whether Web enrollment is required, and, if so, whether it should be installed on the CA or on a different computer. While a Windows Server 2003–based CA requires the Web enrollment support component to be installed, the CA can function without Internet Information Services (IIS) or the Web enrollment pages. A Windows Server 2008–based CA does not require Web enrollment support to be installed.
If you decide that you need Web enrollment, you can either upgrade it in place, or if you have installed it on the CA and want to move it to a dedicated computer, you can perform a migration by removing it from the CA and installing it on the target computer. If you have Web enrollment pages installed on a separate server, you should upgrade this server first and then move on to the CA or other PKI components.
The following figure illustrates the general workflow for upgrading Web enrollment pages.
.gif)
Example: Contoso Upgrade and Migration Approach
Considering all the options and requirements previously discussed, the overall upgrade and migration approach will most likely fit into one of the following categories:
In-place upgrade
Upgrade with migration
Phased upgrade
Contoso, a fictitious company, is running a complex PKI that requires upgrade and migration. Because of the number of CAs in its network, all three approaches have to be applied. At least one CA can be upgraded as an in-place upgrade, other CAs require upgrade with migration, and, because of the size of its environment, the upgrade needs to be in phases to minimize downtime.
Contoso's Current PKI
As shown in the following illustration, Contoso has two Active Directory forests running on Windows Server 2003–based domain controllers and client computers running Windows XP with SP2 and Windows Vista. The computers running Windows XP with SP2 are currently being upgraded to Windows Vista.
Note
For this example, Contoso's PKI contains some intentional misconfigurations to help illustrate migration scenarios.
.gif)
Contoso has a three-tier CA topology with the following configuration:
A single offline stand-alone root CA (CA1) installed on a workgroup (not a domain member) computer running Windows 2000 Server with SP4.
Two stand-alone intermediate CAs (CA11 and CA12). CA11 is a stand-alone CA that was unnecessarily installed on a domain member in forest A on a computer running Windows Server 2003 Enterprise Edition. CA12 is a stand-alone CA running on a Windows Server 2003 Standard Edition–based workgroup computer.
Three enterprise issuing CAs (CA111, CA112, and CA122) running on Windows Server 2003 Enterprise Edition–based domain members. MSCEP is installed on CA111.
One stand-alone issuing CA (CA121) in forest B.
One enterprise CA (CA123) installed on a domain controller.
CA Web enrollment pages installed on a separate domain member running Windows Server 2003 in forest a.contoso.com. Clients can use that server to enroll for certificates from issuing CA112.
An HTTP CRL and authority information access distribution point consisting of two clustered servers running Windows Server 2003 Enterprise Edition, with IIS installed on each. (Enterprise edition is required to use NLB with IIS.)
Business Challenge
Contoso is facing several of the following reasons for upgrade and migration:
Contoso is interested in deploying restricted enrollment agents and OCSP to enhance the security and availability of its existing PKI. In addition, the company is interested in deploying certificates that use CNG but is not sure if it needs to deploy immediately. However, Contoso would like to ensure that any short-term deployments do not restrict the option to migrate to CNG in the next three to five years.
Contoso also wants to move CA123 away from the domain controller.
Because the root CA is still on a server running Windows 2000 Server, Contoso needs to upgrade this CA to a Windows version that is still within the support lifecycle.
Design Considerations
In determining their upgrade and migration approach, Contoso considered the following:
AD CS in Windows Server 2008 remains a forest-level resource, as it was in Windows Server 2003. Therefore, AD CS must be deployed in each forest in which certificates are required. An exception is the stand-alone root CA, which can sign CA certificates for Windows CAs residing in multiple forests.
Because the stand-alone root CA is running Windows 2000 Server with SP4, it will reach the end of the extended support period by July 2010. This is a requirement to move the CA to a Windows version that has not reached the end of its support lifecycle.
Enforcing restricted enrollment agents will require at least one CA to be upgraded to Windows Server 2008, in each forest in which the feature is required. Enrollment agents are supported with Windows Server 2003, but they cannot be restricted.
Deploying the Online Responder for OCSP will require at least one server running Windows Server 2008 on which IIS can be installed. Ideally, the Online Responder should be clustered for redundancy.
Deploying the Online Responder will require the CAs for which OCSP revocation checking is required to be either upgraded to Windows Server 2008 or to update the configuration of the Windows Server 2003–based CA as noted in the Online Responder Mixed Scenarios entry in the previous table. For more information, see Installing, Configuring, and Troubleshooting the Online Responder (https://go.microsoft.com/fwlink/?LinkID=101269).
Deploying OCSP will require certificate templates to be upgraded because the OCSP certificate template is new in Windows Server 2008.
To allow for future deployment of CNG, the root and policy CA keys should be evaluated for upgrade to CNG-based keys, which require Windows Server 2008.
For redundancy, clustering should be considered for the CAs. Redundancy for certificate enrollment is provided automatically if the same certificate templates and permissions are assigned to multiple issuing CAs, but active/passive failover clustering requires the failover clustering feature of Windows Server 2008.
The CA installed on the domain controller should be moved to a domain member server. This consideration is a best practice.
Each CA that is connected to an HSM will require vendor-specific upgrade and migration steps.
To support client computers running Windows Vista, Web enrollment pages will need to be upgraded to Windows Server 2008.
Contoso Upgrade and Migration Solution
After evaluating the requirements and design considerations, Contoso decided on the following upgrade and migration approach:
Upgrade CA1 to Windows Server 2003 and optionally to Windows Server 2008.
Migrate CA11 to a stand-alone CA on a computer that is not joined to the domain.
Consolidate CA111 and CA112 as a new clustered issuing CA named CA113.
This step requires the removal of MSCEP from CA111 because MSCEP cannot be used in a cluster.
Upgrade the Web enrollment server to Windows Server 2008 and configure it to connect to the new cluster CA113.
Install the Network Device Enrollment Service on the upgraded Web enrollment server running Windows Server 2008.
Remove CA123 from the domain controller and migrate CA123 to a Windows Server 2008–based CA.
Upgrade CA122 in place to Windows Server 2008.
Decommission CA121. (This should be done only if there is no requirement for a stand-alone issuing CA. To continue providing revocation information for any certificates issued by this CA, publish a long-lived CRL before taking the CA offline).
Deploy a new Online Responder cluster to support the CAs in each forest.
To configure the Online Responder to support a CA, the Online Responder must be configured with an OCSP Response Signing certificate issued by the CA. For more information about configuring the Online Responder, see Installing, Configuring, and Troubleshooting the Online Responder (https://go.microsoft.com/fwlink/?LinkID=101269).
The following diagram shows the target CA environment at Contoso.
.gif)