Exploring Windows 2003 Security: More About Certificate Services

The previous article in this series began our coverage of new functionality implemented in the Windows 2003 Certificate Services. We continue the topic here with the exploration of the following features:

• Separation of Certificate Management roles
• Qualified subordination and cross-certification
• Delta updates to the Certificate Revocation List
• More detailed auditing capabilities

Separation of Certificate Authority Management Roles

We continue our coverage of new functionality implemented in the Windows 2003 Certificate Services with the exploration of the separation of Certificate Management roles, qualified subordination and cross-certification, delta updates to the Certificate Revocation List, and the more detailed auditing capabilities now available.

Both Windows 2000 and Windows 2003 support role-based administration of Certificate Authorities (CAs). This means that responsibilities and corresponding permissions or user rights are divided into several distinct, mutually exclusive, categories (this does not, however, apply to read permissions, which are implicitly assigned to members of every role). Windows 2003 CA can operate with four predefined management roles (the first two are specific to CA, the remaining two are systemwide). The first two roles are associated with permissions assigned via the Security tab of the CA server properties dialog box in CA MMC snap-in, while the last two are associated with user rights, granted via group policy settings (Computer Configuration->Windows Settings->Security Settings->Local Policies->User Rights Assignment node).

• CA Administrator grants “Manage CA” permission, which provides the ability to configure CA properties, assign roles to other users, and renew CA certificates.
• Certificate Manager grants “Issue and Manage Certificates” permission, which allows managing certificate enrollment, initiating private key recovery, and Certificate Revocation List.
• Backup Operator grants “Backup files and directories” and “Restore files and directories” user rights, which allows backup and restore of certificate stores.
• Auditor grants “Manage auditing and security log” user rights, which allows the configuration and viewing of security-related events.

The main advantage, in terms of security, of implementing management roles in Windows 2003 CA is the ability to separate roles. This ensures a particular user can be a member of only one single role, which significantly decreases the probability of endangering the entire system, should an individual account be compromised.

To enable role separation, you should first ensure that no users are sharing multiple CA-related roles (otherwise these users will be prohibited from performing any CA-related tasks once separation is enforced). Once this has been verified, at the Command Prompt, type in:

certutil -setreg caRoleSeparationEnabled 1

This sets the

registry entry to 1.

To disable it, simply remove the entry by running the following.

HKLMSYSTEMCurrentControlSetServicesCertSvcConfgurationComputerNameRoleSeparationEnabled 

certutil -delreg caRoleSeparationEnabled

To ensure that the change took effect, restart the CA service. You can do this from the CA MMC snap-in, from the Services MMC snap-in, or from the command line by typing

and

net start certsvc

Implementing this feature has a surprising side effect, however. Since the local administrator account on the CA server has, by default, the rights of CA Backup Operator and CA Auditor, once the role separation is enabled, it can no longer perform any CA-related administrative tasks. To avoid this issue, make sure to designate nonadministrative accounts for each of the roles (which is the recommended practice from the security perspective). Remember also that role separation is limited to the Enterprise and Datacenter editions of Windows 2003 (although role-based administration is also available in Windows Server 2003).

In addition to role assignment and separation, you can delegate the management of certificate templates. Permissions for existing ones are set using the Security tab of their Properties dialog box in the Certificate Templates MMC snap-in. To delegate permissions to create or duplicate existing templates, modify the access control list on objects in Configuration naming context of Active Directory.

More specifically, you must grant Full Control permissions to the CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=ForestRoot container and each of templates stored in it (since permissions are not inherited) and to the CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=ForestRoot container. To modify Access Control List on Active Directory objects, use ADSI Edit or LDP Windows 2000 Support Tools utilities.

Qualified Subordination and Cross-certification

In Windows 2000, you could build a hierarchy of CA servers, with a single root and multiple subordinates. Typically, the purpose of such a structure was to segregate servers according to their roles and desired level of security. A root server, maintained in a highly protected environment (or even brought online only when necessary), could be used strictly for issuing CA certificates to subordinate CAs, which authorized them to issue their own certificates directly to users and computers (or authorize CA servers lower in hierarchy). However, there was no mechanism for creating a CA structure consisting of multiple hierarchies tied together (derived from multiple roots). As a workaround, you could create Certificate Trust List (CTL) containing root certificates of other Certificate Authorities and set the validity period and restrictions on purpose for each.

This functionality is still supported in Windows 2003 Server CA; however, you can now also link any number of CA hierarchies using cross-certification and, at the same time, limit their scope by applying qualified subordination. This offers much greater control over the level of trust granted to other CA hierarchies. In particular, restrictions imposed on certificates by qualified subordination can include any of the following:

• Basic Constraints limiting the number of levels of CA subordinates that can exist in the hierarchy. For example, in the most extreme case, you can set the length of the certificate path to zero, which will prevent the target CA (on which constraint is placed) from issuing any subordinate CA certificates (and, effectively, limit them to providing end-entity certificates).
• Name Constraints limiting subject names for which a certificate can be issued. (This can include relative distinguished names, DNS domain names, e-mail or user principal names, and IP addresses.) For example, you would typically want to prevent CAs from other organizations from issuing certificates containing names specific to yours.
• Application Constraints limiting the purpose of certificate (e.g., to Client Authentication, CA Encryption, Smart Card Logon, Document Signing, File Recovery, Key Recovery, Microsoft Trust List Signing, or Qualified Subordination)/
• Policy Constraints limiting certificates to those that follow specific types of issuance procedures as determined by identifiers assigned to certificate templates on which these certificates are based. For example, you might want to restrict accepted certificates issued by another CA to those for which a requester has been a subject to an extra background check.

Note that qualified subordination can be applied independent of cross-certification (e.g., to restrict a certificates issued by a subordinate CA within single a CA hierarchy to a specific namespace). However, both of these features are also commonly combined to provide interoperability between two (or more) CA hierarchies with a configurable level of trust. You can, for example, configure cross-certification between two root CAs or between between subordinate and root CAs, allowing trust between all or a limited range of CAs in both hierarchies. In either of these scenarios, you can apply any combination of constraints. You can also use a bridge CA to provide qualified subordination among more than two CA hierarchies.

The implementation of qualified subordination is possible only with CAs installed on Windows 2003 Enterprise and Datacenter Servers and involves two types of certificates based on version 2 templates. The first is the Cross-Certification Authority Certificate, which is issued from a CA in one hierarchy to a CA in another (this is typically initiated based on request generated with CERTREQ.EXE utility), and the second is a Qualified Subordination Signing Certificate — which contains the Qualified Subordination application policy identifier necessary for signing the Cross-Certification Authority certificates. This type of certificate must be issued to a CA administrator responsible for setting up qualified subordination.

The constraints for qualified subordination is definable in one of two ways:

1. During installation of qualified subordinate CA (by making manual modifications to the CAPolicy.INF file: This file must be stored in the %SystemRoot% directory prior to installation of the CA component on the target server). This is typically used to specify constraints for subordinate CA within a single CA hierarchy.
2. During the creation of a request for cross-certification authority certificate (by making manual modifications to an .INF file: You are prompted for this file when generating the cross-certification authority certificate request with CERTREQ.EXE command line utility). This is typically used to specify constraints for existing CAs in two or more hierarchies, when configuring cross-certification.

For detailed information on cross-certification and qualified subordination (including a description of syntax of CAPolicy.INF file), refer to the Microsoft Web site.

Delta Certificate Revocation List

The Certificate Revocation List is a list of revoked certificates issued by a particular CA. The list is digitally signed (by the same CA that issued and revoked the certificate), and each certificate on it is identified by its serial number. The list also contains the date on which each certificate was revoked and reason for the revocation (e.g., compromise of the certificate and its subject being no longer valid).

As you can imagine, it is critical that the updated CRL is available to all clients. Certificates are added to the list right after they are revoked by a CA administrator (typically by using CA MMC snap-in); however, they are published according to the configurable schedule, based on the publish period value. By default, this value is set to one week, but it can be shortened to one hour, if necessary, or, alternatively, extended up to 9,999 years).

This is configurable from the Revoked Certificates Properties dialog box, accessible from the CA MMC snap-in. Clients participating in activities requiring certificates (this applies to both users and computers) download published CRLs whenever needed. Downloads originate from distribution points specified on the Extension tab of the CA Properties dialog box in the CA MMC snap-in and can include Web servers, network file shares, Active Directory, or local file system path on the CA server. Once downloaded, CRLs are cached on a client computers for configurable validity period (by default, this is 10 percent longer than the publish period).

In Windows 2000, any changes to the CRL detected by clients during refresh (once the validity period expires) would force them to request entire list again. With Windows 2003 CA, network bandwidth usage can be limited by allowing incremental updates via delta CRL, containing only changes applied since the most recent download. The period of publishing delta CRL is configurable from the Revoked Certificates Properties dialog box.

Enhanced Auditing

CA-related events (such as key storage and recovery, certificate revocation, or role assignments and changes) can be recorded in the Security event logs. This requires selecting the appropriate checkboxes on the Auditing tab of the CA Properties dialog box in the CA MMC snap-in, as well as enabling the auditing of object access via Group Policy (Computer Configuration->Windows Settings->Security Settings->Local Policies->Security Options).

This article was originally published on Oct 7, 2003

Advertiser Disclosure: