Windows Server 2003 PKI and Dependencies (Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure)
Applies To: Windows Server 2003 with SP1
From a technical perspective, a Windows Server 2003 PKI has some requirements before you can deploy it. This section describes fundamental process information and installation details for a successful Windows Server 2003 PKI implementation.
New Features of a Windows Server 2003 CA
Windows XP and Windows Server 2003 environments can benefit the most from all of the features of the Windows Server 2003 certification authority (CA), but mixed configurations with earlier versions of Windows are also supported, with a little less functionality.
The following table lists the features that are described later in this section. These features are available through the CA if the CA is installed on a specific version of the operating system.
Table 1 PKI feature support with a CA that is installed on different versions of the operating system
| Windows Server 2003, Enterprise Edition or Datacenter Edition | Windows Server 2003, Standard Edition | Windows 2000 Server | |
|---|---|---|---|
V2 templates |
Enterprise CA only |
Not supported |
Not supported |
Key archival and recovery |
Supported |
Not supported |
Not supported |
Auto-enrollment |
Both user and computer certificates supported |
Computer certificates supported |
Computer certificates supported |
Delta certificate revocation lists (CRLs) |
Supported |
Supported |
Not supported |
Qualified subordination |
Supported |
Supported |
Not supported |
Role separation |
Supported |
Not supported |
Not supported |
Note
Windows Server 2003, Web Edition does not include certification authority functionality, but may be used as a PKI client.
The following table lists the features that can be used at the client with a given CA infrastructure:
Table 2 PKI features that are available to clients
.gif "Art Image")
For additional information, see the following articles:
What's New in Security for Windows XP Professional and Windows XP Home Edition on the Microsoft Web site
Data Protection and Recovery in Windows XP on the Microsoft Web site
Version 2 Templates
Templates are the building plan for certificates. A template turns a certificate request into a certificate signed with the CAs private key. For example, a template defines the validity time of a certificate and the certificate's subject name.
The most significant difference between the version 1 (V1) and version 2 (V2) templates is that V1 templates are predefined and unchangeable. With V2 templates, a CA administrator is able to configure a wide range of settings that apply during certificate enrollment, such as minimum key length, subject name definition, enrollment requirements like enrollment agent signature, and so on.
V2 templates are available only with an enterprise CA that is running Windows Server 2003, Enterprise Edition or Datacenter Edition. An enterprise CA that is running Windows Server 2003, Standard Edition does not support V2 templates.
Generally, templates are stored in the Active Directory configuration naming context and are usable with any CA in an Active Directory forest if they are assigned to the CA. A single set of templates are available for use by all CAs in the forest. However, V2 templates can only be utilized with Windows Server 2003, Enterprise Edition or Datacenter Edition CAs.
To use V2 templates, the Active Directory schema must be extended to the Windows Server 2003 schema in the forest. If the Active Directory environment consists of Windows Server 2003 domain controllers only, no action is required to benefit from a Windows Server 2003 PKI. If all domain controllers of a forest that hosts the Windows Server 2003 CAs are running Windows 2000 Server, you must also install Microsoft Windows 2000 Service Pack 3 (SP3) or later on all domain controllers, in addition to the new Windows Server 2003 schema definitions. For more information about how to upgrade the schema, see Prepare the Active Directory environment in this document.
For more detailed information about certificate templates, their usage, and their definition capabilities, see "Certificates" in the Windows Server 2003 Family Help.
For more information about certificate enrollment, see "Certificate Enrollment" in the MS Windows 2000 Public Key Infrastructure Introduction white paper on the Microsoft TechNet Web site.
For more information about extending the schema for V2 templates, see the Windows Server 2003 Help topics regarding certificate templates.
Certificate Enrollment
You can enroll V2 templates with any computer running Windows XP or later through the default enrollment methods, including the Certificates Microsoft Management Console (MMC), the built-in auto-enrollment mechanism, Web enrollment support, or command-line tools.
A computer running Windows 2000 cannot use the Certificates MMC to enroll a V2 template. However, any client that is running Microsoft Internet Explorer 5.01 or later can use a V2 template to enroll certificates through the Web enrollment methods and a downloaded ActiveX control. To download the ActiveX control on a client computer, it is necessary to log on as an Administrator or Power User on the local computer. In addition, clients running Windows 2000 can enroll V2 templates through a Terminal Server connection running on an appropriate member of the Windows Server 2003 family.
Note
An enrollment agent that enrolls certificates that are based on V2 templates requires either a Windows XP or Windows Server 2003 enrollment station. There is no support to enroll V2 templates with an enrollment agent on a Windows 2000 enrollment station. Nevertheless, certificates that are based on V2 templates that have been enrolled through an enrollment agent on either a Windows XP or Windows Server 2003 enrollment station can be used on a Windows 2000 client computer.
If certificates have been enrolled with a Windows 2000 PKI where only V1 templates were available, there is no immediate need to re-enroll or renew these certificates with V2 templates.
The following table lists different enrollment methods that are supported on computers that are running Windows 2000, Windows XP, or the Windows Server 2003 family. You can use scripted enrollment with support of CAPICOM and Xenroll. (CAPICOM and Xenroll documentation, including samples, can be found on the Microsoft Developer Network (MSDN) Web site.)
Table 3 Certificate Enrollment
| Certificates MMC | Web-enrollment | Scripted enrollment | |
|---|---|---|---|
Self enrollment on a Windows 2000 workstation |
V1 template: Yes V2 template: No |
V1 template: Yes V2 template: Yes |
V1 template: Yes V2 template: Yes |
Self enrollment through a Windows Server 2003 Terminal Server session |
V1 template: Yes V2 template: Yes |
V1 template: Yes V2 template: Yes |
V1 template: Yes V2 template: Yes |
Enrollment agent on a Windows 2000 workstation |
V1 template: No V2 template: No |
V1 template: Yes V2 template: No |
V1 template: No V2 template: No |
Enrollment agent through a Windows Server 2003 Terminal Server session |
V1 template: No V2 template: No |
V1 template: Yes V2 template: Yes |
V1 template: No V2 template: No |
Note
Because a PKI is a forest resource, the Active Directory site structure is not taken into account when any kind of certificate is requested and issued. An Active Directory–integrated certificate requester enumerates all registered enrollment services in Active Directory and sends its request to a CA that can enroll the certificate type that the user wants. The client does not necessarily choose the closest CA, from a network perspective. Because of this, you should verify that the CA deployment ensures that any client has reliable network connectivity with a CA.
User Certificate Autoenrollment
Autoenrollment provides a quick and simple way to issue user certificates and to benefit from applications that can use PKI. User autoenrollment also minimizes PKI deployment costs.
Certificate autoenrollment also works in a Terminal Server session if you use a Windows Remote Display Protocol (RDP) 5.1 client.
When you use a computer that is running Windows XP, you can automatically enroll users and computers for certificates, including smart card-based certificates. In contrast, the Windows 2000 Server family only supports certificate autoenrollment for computer certificates. User certificate auto-enrollment builds on the standard Windows security model for domain authentication and authorization. This model may not be suitable for all certificate issuance or scenarios.
Using the new autoenrollment feature, organizations can manage the certificate lifecycle through V2 templates for users. This includes:
Certificate renewal
Superseding of certificates
Multiple signature requirements
Depending on the configuration of the template that is used for autoenrollment, the user can be notified when a certificate enrollment or renewal is performed.
Certificate autoenrollment is based on the combination of Group Policy settings and V2 certificate templates. This combination allows certificate enrollment and renewal in the background for computers and users at any time when you apply Group Policy.
To perform autoenrollment, the certificate requester must be registered and authenticated as either a user or computer in Active Directory.
For more information, see Certificate Autoenrollment in Windows Server 2003 on the Microsoft TechNet Web site.
Certificate Renewal
When a certificate comes to the end of its lifetime, it must be renewed or replaced to ensure that the certificate owner is able to continue with the certificates purpose.
In certificate renewal, the renewal requester already owns a certificate. The renewal takes the information of the existing certificate into account when the renewal request is submitted. A certificate can either be renewed with a new key or the existing key can be used for the renewed certificate.
If a certificate was enrolled with a V2 template, it cannot be renewed if it was based on a V1 template. However, a certificate that was enrolled with a V1 template can be renewed with a certificate that was made from a V2 template.
Table 4 Certificate Renewal
| Certificates MMC | Web-enrollment | Scripted enrollment | |
|---|---|---|---|
Self renewal on Windows 2000 workstation |
V1 template: Yes V2 template: No |
V1 template: No V2 template: No |
V1 template: Yes V2 template: Yes |
Self renewal on Windows 2000 workstation with Windows Server 2003 Terminal Server session |
V1 template: Yes V2 template: Yes |
V1 template: No V2 template: No |
V1 template: Yes V2 template: Yes |
Renewal with enrollment agent on Windows 2000 workstation |
V1 template: No V2 template: No |
V1 template: No V2 template: No |
V1 template: No V2 template: No |
Renewal with enrollment agent on Windows 2000 workstation with Windows Server 2003 Terminal Server session |
V1 template: No V2 template: No |
V1 template: No V2 template: No |
V1 template: No V2 template: No |
Key Archival and Recovery
Key archival and recovery is only available for encryption certificates by V2 templates, because the archival option must be individually set for each template. Key archival is most often used for encryption keys that are used to protect persisted data.
Private keys that are associated with certificates that are used only for digital signature are not archived and are blocked by the certification authority. The archival and recovery function that is available with the Microsoft Exchange 2000 Key Management Server (KMS) has been replaced by the enterprise CA running Windows Server 2003, Enterprise Edition.
The enterprise certification authority on a computer that is running Windows Server 2003, Enterprise Edition, supports migration of the archive database from the Exchange 2000 KMS to ensure a smooth transition of technologies.
Encrypting File System (EFS) will continue to support decentralized data recovery methods as well as key archival on clients that are running Windows XP.
Delta CRLs
Delta certificate revocation lists (CRLs) decrease the network traffic that is caused when a new certificate revocation list needs to be downloaded. Without delta CRLs, a client must receive the base CRL that contains all certificates that are revoked by a CA. To decrease the CRL's size and make more frequent updates valuable, delta CRLs only retain the certificates that have been revoked since the last publication of the base CRL.
Some limitations apply to delta CRLs:
Delta CRLs are issued by Windows Server 2003 stand-alone and enterprise CAs.
Only clients that are running Windows XP Professional and later are able to check the validity of certificates against delta CRLs.
For more information about this topic, see Troubleshooting Certificate Status and Revocation on the Microsoft TechNet Web site.
Qualified Subordination
Qualified subordination allows cross-certification of CA certificates with name constraints and provides for more precise control of certificate trusts. With qualified subordination, an administrator can also include or exclude certificate purposes. For example, qualified subordination might reject Internet Protocol security (IPSec) usage with a third-party certificate, but allows secure e-mail with the same certificate, even if the certificates key usage would allow IPSec and secure e-mail.
Qualified subordination requires a Windows XP or Windows Server 2003 operating system as the certificate requester and a Windows Server 2003, Enterprise Edition CA.
Simple Certificate Enrollment Protocol
You can implement secure networking with the Simple Certificate Enrollment Protocol (SCEP). The Microsoft SCEP (MSCEP) component is an Internet Server Application Programming Interface (ISAPI) filter that uses Microsoft Internet Information Services (IIS) and is installed directly on a CA to support the SCEP enrollment protocol with network devices.
For more information, see article 249125, Using Certificates for Windows 2000 and Cisco IOS Interoperation, in the Microsoft Knowledge Base.
Role Separation
There are a number of tasks in the PKI process that you should understand:
Certificate enrollment. Sends a certificate request to the CA, and then the CA issues the certificate and then deploys a certificate to the certificate holder.
Certificate renewal. Sends a request to renew an existing certificate to the CA, the CA issues the certificate, and then the CA deploys a certificate to the certificate holder.
Certificate revocation. Revokes certificates and publishes the certificate revocation list (CRL).
Recovery. Provides the certificate holder with both a certificate and a key that are stored in the CA database.
There are also a number of roles that are related to a Windows Server 2003 CA, although you may not need all of these roles:
The CA manager maintains the CA and its configuration.
The CA administrator delegates certificate-management permissions to Certificate Managers.
The certificate manager issues and revokes certificates.
The enrollment agent requests and deploys certificates.
The certificate holder requests self-maintained certificates and is able to use the certificate.
The recovery agent recovers certificates for specific applications, such as EFS.
The following table shows which role can perform a particular task and what permissions are required to perform that function. The top row lists various roles, and the left column lists the tasks. The table text describes the permission that is required to perform each task.
Table 5 Certificate Roles and Tasks
| Certificate Holder | Enrollment Agent | Recovery Agent | Certificate Manager | CA Manager | |
|---|---|---|---|---|---|
Maintain |
Not applicable |
Not applicable |
Not applicable |
Not applicable |
Requires CA Manager permissions on the CA object |
Request |
Requires certificate holders membership on the certificates template ACL |
Requires certificate holders membership on the certificates template ACL |
Not applicable |
Not applicable |
Not applicable |
Renew |
Requires certificate holders membership on the certificates template ACL |
Requires certificate holders membership on the certificates template ACL |
Not applicable |
Not applicable |
Not applicable |
Issue |
Not applicable |
Not applicable |
Not applicable |
Certificate Manager permission on a template |
Not applicable |
Revoke |
Not applicable |
Not applicable |
Not applicable |
Certificate manager permission |
Not applicable |
Recover |
Not applicable |
Not applicable |
Key recovery agent certificate |
Not applicable |
Not applicable |
CA Permissions
For a Windows Server 2003 stand-alone CA that is installed on a server that is not a member of an Active Directory domain, local administrator permissions are mandatory to manage the CA functions.
On a server that is a domain member, the user who installs an enterprise CA must be a member of the Active Directory Root Domain Admins and Enterprise Admins security group. You should ensure that the installation account is a member of both security groups. This set of permissions is required for any enterprise CA installation, and it assumes that the Enterprise Admins group or Domain Admins group also is a member of the local server Administrators group. To install a stand-alone CA, only local administrator privileges are required.
During setup, containers and objects that contain enrollment and CA information are created as part of the configuration container of Active Directory. For a list of object default permissions that are used by a CA, see article 239706, "Default Permission Settings for Enterprise Certificate Authority," in the Microsoft Knowledge Base.
It is recommended that you use only the Certification Authority MMC to change security permissions for the CA. If you use other mechanisms, such as the Active Directory Sites and Services MMC, you may cause an unsupported environment due to a configuration mismatch between Active Directory and the local CA registry. The Certificate Templates MMC ensures consistency in the ACLs. If ACLs are changed manually, specific permissions may be missing and the CA will not function as expected.
Command-line Administration Tools
Command-line administration tools are part of the Windows Server 2003 family and may be installed on computers running Windows XP and later through the Windows Server 2003 Administration Tools Pack, which is available on the Windows Server 2003 installation media. Command-line tools that are required for CA administration on Windows 2000 operating systems are only installed with Windows 2000 Certificate Services. For more information about Certutil.exe and Certreq.exe, including a description and the necessary syntax, see the Windows Server 2003 Help.
CA Fault Tolerance
Generally, you should use certification authority fault tolerance because:
For online CAs, it provides certificate issuance services.
For both online and offline CAs, it provides certificate revocation information.
Neither Windows 2000 nor Windows Server 2003 technology supports native clustering of the CA database or certificate services. Only one CA instance can be installed at a time on a server running a Windows Server 2003 operating system.
An enterprise CA is designed to provide natural fault tolerance in an Active Directory environment. If one enterprise CA does not work or is not available, client services will automatically attempt enrollment with the next available enterprise CA in the forest. No errors are generated and no user interaction is required. For more information, see "Online Enterprise Issuing CAs" later in this document.
If a CA is not available because of a hardware failure, for example, it might still be necessary to publish the CRL on a regular basis. The CRL publication interval depends on the CA configuration. If the CA does not publish the CRL in time, clients cannot verify certificates against the latest version of the CRL.
To publish a CRL on behalf of a CA, you must own the CA private key. If the CA private key has been exported to a file, it is technically possible to resign a CRL on behalf of the CA and extend the lifetime of the CRL.
Note
Exporting the CA private key could raise a security risk because the owner of the CA's private key is able to act on behalf of the CA. The CA private key must be maintained very carefully and must be stored in a secure vault that is protected through secure and audited processes.