Exploring Windows 2003 Security: Certificate Services

Implementing Certificate Services in Windows 2000 (included in Standard, Advanced, and DataCenter editions) provided the ability to manage Public Key Infrastructure; however, several limitations affected its acceptance on a wider scale. Improvements introduced in the Certificate Services available in Windows 2003 (also offered on the same three server platforms — Standard, Enterprise, and DataCenter) elevated Public Key Infrastructure to the level of a truly corporate, easily manageable, and scalable solution.

A host of improvements were made to Certificate Services in Windows Server 2003. This installment of our ‘Exploring Windows 2003 Security’ series examines the operating system’s enhanced certificate management tools, support for Certificate Templates, improved autoenrollment and autorenewal capabilities, and simplified private key archival and recovery.

This article covers the following improvements made to Certificate Services in Windows Server 2003:

• Enhanced certificate management tools
• Support for Certificate Templates version 2
• Improved autoenrollment and autorenewal capabilities
• Simplified private key archival and recovery

Certificate Administrative Tools

Before we examine the specifics of a Windows 2003 Certificate Authority (CA) implementation, a review of the toolset is in order.

• Certification Authority (CA) MMC snap-in enables you to configure the CA component running on Windows Server 2003, whether it’s the Standard, Enterprise, or DataCenter version. Although this was also available in Windows 2000, the amount of configuration options has increased.
• Certificates MMC snap-in operates in the same fashion as its Windows 2000 counterpart by allowing you to view certificate store for user, service, and computer accounts.
• Certificate Templates MMC snap-in, new in Windows 2003, allows cloning and editing Certificate Templates, which was was not previously possible. We will review its options during our discussion of Certificate Templates version 2 and private key archival later in this article.
• CERTUTIL command line utility is one of Microsoft’s many command line capabilities. The versatility of this tool is seen by simply typing CERTUTIL /? at the command prompt, which then brings up a long listing of available options. We will look at some of its functionality in the next article, when we discuss role separation in CA management.

Custom Certificate Templates, Version 2

Certificate Templates serve as a collection of properties and rules determining the nature and behavior of certificates derived from them. For example, processes for issuing and renewing certificates, as well as their validity or renewal periods, are governed by their templates settings. Several predefined, nonmodifiable Certificate Templates (version 1) were introduced in Windows 2000 CA that provide basic signing and encryption functionality (within areas such as Encrypted File System, Exchange 2000 e-mail, SmartCards logons, and code signing)

Certificate Templates version 1 are still available in Windows 2003; however, Enterprise and DataCenter servers hosting CAs can also issue certificates based on Certificate Templates version 2 (with Standard server, version 2 templates can be created but not issued). In addition, even though version 1 templates are still read-only and cannot be modified directly, you can duplicate them, which, in turn, automatically updates them to the new version.

Version 2 templates are not only modifiable, but they can also be duplicated and extended. Duplication of existing version 1 and version 2 templates and customization is typically done with Templates MMC snap-in, allowing you to change practically every template property, including various policies (e.g., relating to key usage and archiving, validity period, or enrollment), issuance requirements (determining whether enrollment request requires CA manager approval), request handling (e.g., specifying whether autoenrollment is possible), certificate purpose (encryption, signature, or both), Cryptographic Service Provider (CSP), or superseding (which allows you to replace existing certificates with new ones). It is important to remember that changes to templates are forestwide, since all CAs in the forest use the same set of templates (stored in the CN=Certificate Templates,CN=Public Key Services,CN=Services,DC=ForestRootDomain Active Directory container).

Note that only the Enterprise version can issue version 2 templates (not stand-alone) CAs, require Windows 2003 Active Directory environment (with schema updated by running ADDPREP /Forestprep), and they apply only to Windows XP Professional and Windows Server 2003 systems. A number of features described further in this article (such as autoenrollment and autorenewal) are available only for certificates based on version 2 templates.

Windows 2003 predefined Certificate Templates version 2 include the following:

• CA Exchange: Encryption of keys maintained by and exchanged among CA servers
• Cross Certification Authority: Signing involved in cross-certification and qualified subordination (the next article will cover these two topics)
• Directory E-Mail Replication: Signing and encryption of SMTP-based Active Directory replication traffic among domain controllers
• Domain Controller Authentication: Signing and encrypting authentication traffic among domain controllers
• Key Recovery Agent: Encrypting private keys archived on the CA servers (used for private key recovery)
• RAS and IAS Server: Signing and encrypting traffic intended for servers in the RAS and ISA Servers group
• Workstation Authentication: Signing and encrypting authentication traffic between domain member servers and workstations and domain controllers

Certificate Autoenrollment and Autorenewal

Autoenrollment and autorenewal relieves the burden from a user to request certificates; it retrieves and stores them once they are issued, and renews them once they expire. CA in Windows 2000 supported autoenrollment, but limited it strictly to certificates used for Encrypted File System. Windows Server 2003 has expanded the options in this area. It allows the autoenrollment of both users and computers as long as the certificate being deployed is based on the version 2 template, and an enterprise (root or subordinate) CA Windows 2003 Enterprise or DataCenter server is running in the Windows 2003 Active Directory forest (with updated schema). In addition, autoenrollment and autorenewal is limited to Windows XP Professional clients and Windows 2003 servers. The autoenrollment certificates are deployed via group policies at computer startup or user logon (for computer and user certificates, respectively).

To autoenroll a certificate to users or computers, take the following steps:

1. Ensure the CA issuing the certificate is configured as an enterprise root or subordinate and is running on a Windows 2003 Enterprise or DataCenter server in a Windows 2003 forest. Keep in mind that the autoenrollment will affect only Windows XP Professional and Windows 2003 server systems.
2. Launch the Certificate Templates MMC snap-in and either use an existing template that matches your intended purpose (if it allows autoenrollment) or create its duplicate (if you need to customize it and configure its autoenrollment settings).
3. On the General tab of the certificate template properties dialog box, select the “Publish certificate in Active Directory” check box.
4. In the Subject Name tab, select the “Build from this Active Directory information.” “Supply in the request” option forces the user to provide its subject information interactively, which precludes autoenrollment.
5. On the Security tab of the certificate template properties dialog box, add the target user or computer groups and grant them Read, Enroll, and Autoenroll permissions. Note that since templates are published in the Configuration context of Active Directory, you cannot use domain local groups for assigning permissions.
6. Only one authorized signature can be specified on the Issuance Requirements tab. If the requirement is set to 1, you must also make sure that the policies required in the signature (defined by the listboxes on the same tab), are included in a certificate in the requester’s certificate store (which will allow the automatic attainment of required signatures).
7. On the Request Handling tab, select the “Enroll subject without requiring any user input” option. This enables silent autoenrollment. However, in cases where it might be recommended or required (e.g., in case of autoenrollment of smart card certificates, where users have to insert a smart card into a reader device or type in their PIN), you will need to select the “Require user input for auto-enrollment” checkbox.
   If a new template is created, you might need to wait until the template has been replicated to all domain controllers in the forest before proceeding with the next step.
8. Launch CA MMC snap-in from the Administrative Tools menu.
9. Right-click on the Certificate Templates folder under the CA node, and select the New->Certificate Template to Issue option from the context sensitive menu. This will display the Enable Certificate Templates dialog box, which lists the templates available from the Certificate Templates MMC snap-in.
10. From the list of templates, select the one configured for autoenrollment; click the OK button to validate the choice; and close the Enable Certificate Templates dialog box. The new template will appear in the Certificate Templates folder.
11. Configure deployment of the new template via group policy. Edit the group policy object linked to a container where target users or computer accounts reside. The scope of deployment can be containerwide (such as an entire domain or organizational unit) or narrowed down by applying Security Group or WMI filtering. The decision will depend on the specifics of the environment.
12. From the Active Directory Users or Computers, select the target container. From the Group Policy tab of the container’s properties dialog box, create a new (or use an existing) Group Policy Object, and click on the Edit button. This will display the Group Policy Object Editor window.
13. If the target is a computer, use the Computer Configuration node; otherwise, select User Configuration, and drill down to Windows Policies -> Security Policies -> Public Key Policies. Right-click on the Autoenrollment Settings entry, and display its Properties dialog box. Select the “Enroll certificates automatically” option and both checkboxes underneath it (“Renew expired certificates, update pending certificates, and remove revoked certificates” and “Update certificates that use Certificate Templates” checkboxes).
14. Note that you can force autoenrollment policy to take effect by using GPUPDATE command line utility.

You can configure each of the Certificate Templates to be published in Active Directory and set permissions to allow certain group of users or computers to automatically enroll. The configuration tasks are handled from the Certificate Templates MMC snap-in. On the General tab of the Properties dialog box of each Certificate Template, you can specify whether you want it to be published in Active Directory; from the Request Handling tab, you can permit enrollment without requiring any user input; and on the Security tab, you can set Enroll and Autoenroll permissions (all three are needed for autoenrollment to take place).

Private Key Archival and Recovery

The concept of security provided by the Public Key Infrastructure is based on principle of a key pair, which is formed by a private key and a public key contained within a certificate. Information encrypted with one key can be decrypted with the other; hence, this mechanism is often described as asymmetrical. Access to a public key, as its name indicates, is not restricted (public keys are available with their certificates). Access to the private key, on the other hand, is limited to a single entity (typically a user or computer) and (optionally) a CA administrator (for recovery purposes). Once both keys and corresponding certificate are created and the ownership of the private key assigned, they can be used for two main purposes.

Signing: In this case, the goal is to ensure information integrity. The owner of the private key creates a hash of the content, whose integrity must be ensured. The hash is a one-way transformation that results in a relatively short string of characters uniquely identifying the original content. Then, the private key is used to encrypt the hash. The hash and certificate (with public key) are attached to the content. A person verifying its integrity uses the public key included in the certificate to decrypt the hash, which is then compared to another hash, computed independently based on the received content. If the two match, integrity is confirmed.

Encryption: In this case, the goal is to protect information. When using only an asymmetric method, a public key of the intended information recipient (available via certificate) is used to encrypt the content. The recipient then uses a corresponding private key to decrypt it. However, typically this is not exactly how encryption is handled, since asymmetric methods are inefficient when compared to symmetric ones (where the same key is used for encryption and decryption). Therefore, a symmetric key is used to encrypt the content, and then this key itself is encrypted using the public key of the intended recipient. To retrieve the content, the symmetric key is first decrypted with the private key and then used to decrypt the original content.

As you can see, access to the private key is essential in both scenarios. Since a private key is stored by default in a location specific to a user or a computer (i.e., the user’s or computer’s certificate store), it is not unlikely that it might be lost (e.g., due to an computer failure or a file system corruption). To mitigate the consequences of such a loss, Windows 2003 Enterprise and DataCenter Server CA provide the ability to automatically archive private keys at the time their corresponding certificates are issued. (In Windows 2000, archiving keys associated with certificates had to be handled manually.) If a private key is lost, its copy, stored on the CA server, is recoverable.

Note that archival is allowed only for certificates intended for encryption (the purpose of the certificate is determined based on the setting on the Request Handling tab in the Properties dialog box of the corresponding certificate template). This is intentional because allowing the archival and recovery of private keys used for signing could lead to identity theft.

Private key archiving options are configured using settings on the above-mentioned Request Handling tab. As long as the purpose is set to “Encryption” or “Signature and Encryption,” you can select the first option “Archive subject’s encryption private key.” Enabling it will result in archiving the corresponding private key when the certificate is issued. “Include symmetric algorithm allowed by the subject” option allows the inclusion of symmetric algorithms used for encryption (according to the scenario described above, combining symmetric and asymmetric encryption mechanisms) in the certificate request. Subsequently, the same algorithms are included in the certificate. The third option, “Delete revoked or expired certifications (do not archive)” forces the removal of archived certificates once their expiration date is reached (disabled by default). As in Windows 2000, you can also allow the exportation of a private key from a certificate (by checking the appropriately labeled checkbox on the Request Handling tab) to accomodate its backup or transfer. This however, requires manual action by an administrator or certificate subject.

Besides enabling the described-above “Archive subject’s encryption private key” setting on the certificate template level (using Certificate Templates MMC snap-in), you must ensure that the CA server is configured properly. This is done from the Recovery Agents tab (available only in an Enterprise CA implementation) of the CA Properties dialog box in the CA MMC snap-in by selecting Archive the key option and specifying one or more recovery agents capable of recovering this key. This, in turn, requires having Key Recovery Agent certificates issued to one or more Active Directory user accounts. These user accounts are then used in case private keys must be recovered.

This concludes this installement of our “Exploring Windows 2003 Security” series. The next article of this series will continue our exploration of other features relating to Windows 2003 CA.