Version 2 Certificate Templates
For many CA administrators, Version 2 certificate templates are the most important new feature in Certificate Services. (For information about Version 2 templates, see the Web-exclusive article “Certificate Templates,” August 2002, InstantDoc ID 26119, and “Version 2 Certificate Templates,” May 2002, InstantDoc ID 24545). To use Version 2 templates, you must have Windows 2003 Enterprise Edition and you must have installed Certificates Services as an enterprise CA. To view the available templates, launch the Microsoft Management Console (MMC) Certification Authority snap-in from the Administrative Tools program group, expand the CA node, right-click the Certificate Templates node, and select Manage. Alternatively, you can run the MMC from the command line by typing
MMC.EXE
The screen in Figure 1 displays a partial list of the templates that ship with Windows 2003 Enterprise Edition. You’ll note that some templates require a Windows 2003 Enterprise Edition CA while others require a Win2K or later CA. If you double-click a template that requires a Windows 2003 CA, you’ll see that you can edit and customize many of its properties. If, however, you double-click a Win2K CA certificate, you’ll see that you can’t modify the properties (with the exception of security settings). However, you can use the Certificate Templates snap-in to duplicate Win2K CA templates and make them customizable. Simply right-click a template and select Duplicate Template. In the Properties dialog box that appears, you can name and customize the template, as Figure 2 shows.
In the Properties dialog box, tabs correspond with several customizable settings. For example, the Request Handling tab lets you select the purpose (which determines the type of security) for the certificates the template will issue. Your options are signature, encryption, signature and encryption, or smart card logon and signature. If your choice includes encryption, you can choose whether to archive the encryption private key. (I’ll discuss key archival and recovery later in more detail.) The Subject Name tab controls whether identifying information will come from AD when a certificate is issued and what form the subject name will take. You can choose alternate subject names; your choices—Email Address, DNS Name, User Principal Name (UPN), and Service Principal Name (SPN)—appear as a list of check boxes from which you can select more than one.
You select requirements for issuing certificates through the Issuance Requirements tab. For example, you can set restrictions on how many signatures each certificate must have (if you require more than one, you can’t issue a certificate through autenrollment) and application and issuance policies (e.g., assurance requirements). You can specify which templates a new certificate template replaces through the Superseded Templates tab. When a certificate template is replaced, those who hold certificates from the old template must obtain a replacement certificate from the new template before the scheduled expiration.
You can use the Extensions tab to define Application Policies (aka Extended Key Usage) in certificates issued from a template. The Application Policies define the uses to which a certificate can be put. Application Policies include EFS, Client Authentication, Email Security, SmartCard Logon, Code Signing, and Server Authentication. Also on the Extensions tab are Issuance Policies, which define the level of assurance associated with the certificate and contain the location of the Certification Practice Statement (CPS). You can create new levels of assurance from this tab and modify existing ones as required. You use the Security tab to define who can use the template and how. Through this tab, you can grant subjects permission to obtain a certificate through autoenrollment (although how you customize the template might keep a subject from acquiring a certificate in this manner). Also, you must give users read and enroll permissions before they can use autoenrollment.
The CA won’t issue every template listed in the Certificate Templates snap-in. Before a certificate can be issued from a template, including from templates you create, the template must be imported into the Certificate Templates listed in the Certification Authority snap-in. To import a template, in the Certification Authority snap-in, right-click the Certificate Templates node and select New, then Certificate Template to Issue. From the list of available certificate templates displayed, you can select the templates for those certificates you want the CA to issue.
Key Archival and Recovery
Introduced in Windows 2003 Certificate Services, key archival and recovery lets CA administrators configure the CA to archive the private keys associated with issued certificates. To use key archival and recovery, you must have an enterprise CA installed on Windows 2003 Enterprise Edition. When a user loses a private key, the user can request that a key recovery agent recover it from the CA. Windows 2003’s key archival and recovery replaces Microsoft Exchange 2000 Server’s Key Management System (KMS). Key archival and recovery doesn’t replace the function of the EFS Recovery Agent, however. Typically, you use the recovery agent in a variety of situations—not just when users lose the private key associated with their EFS certificate.
You need to plan carefully before you implement key archival and recovery. First, you must designate user accounts as key recovery agent accounts. The number of accounts that you designate will depend on your policies; I recommend that you designate as few key recovery agent accounts as possible. These accounts will be able to extract the archived private keys from the CA. You must protect these accounts and use proper processes to facilitate key recovery and to keep rogue users from obtaining other users’ private keys.
In environments that use certificates for signing operations (e.g., secure email) or for authentication, CA administrators should consider modifying Version 2 certificate templates to ensure that certificates used for these purposes are separate from certificates used for encryption. In addition, CA administrators must ensure that only certificates used for encryption are configured for key archival and recovery; otherwise, with a recovered key, rogue administrators could perform signing operations or authenticate as users. Users would be required to obtain at least two certificates—with one required for signing and one for encryption.
After you have created or identified accounts as key recovery agents, they must obtain Key Recovery Agent certificates. An enterprise CA won’t issue these certificates by default. You must configure the CA to issue them by importing the Key Recovery Agent template, by using the steps I described previously. Accounts can obtain a Key Recovery Agent certificate through the Web-based enrollment tool at http://<fqdnofca>/certsrv. By default, Key Recovery Agent certificates are issued only to accounts that are members of Enterprise Admins. If a key recovery agent account isn’t a member of this group, you can modify the template’s security to grant the account (or a group to which the account belongs) the necessary permissions.
You obtain the Key Recovery Agent certificate by first clicking the link to request a certificate, then clicking the link to submit an advanced certificate request, and finally clicking the link to create and submit a request to this CA. From the drop-down list, you select Key Recovery Agent. Barring any special requirements, you can click Submit. Unless the CA has been configured to do otherwise for Key Recovery Agent certificates, the request will be held pending the CA administrator’s approval. The CA administrator can use the Certification Authority snap-in to approve the request.
To approve the request, the CA administrator can right-click the request in the Pending Requests container and select Issue. The user can obtain the Key Recovery Agent certificate by revisiting the Web site after the request has been granted, clicking the link to check pending requests, then clicking the certificate to install it.
Before the CA can begin responding to requests to archive keys associated with certificates, you must configure the CA to do so. Right-click the CA node in the Certification Authority snap-in, select Properties, click the Recovery Agents tab, then select the Archive the key option. By default, one recovery agent is configured per CA, but you can specify more than one. The recovery agents for the CA must be named. You can select recovery agents by clicking Add and then selecting the key recovery agents’ certificates. After you specify the recovery agents, Certificate Services must be restarted for the changes to take effect. (You’re offered the choice of restarting the server immediately or restarting it later manually.) Figure 3 shows the properties of a CA configured for key archival.
Next, you must modify the properties for each template from which certificates are issued for which you want key archival. If a template is a Version 1 template, you need to duplicate it to create a Version 2 template that can be modified. (You can then configure the template to supersede the template from which it was duplicated.)
When a user notifies a key recovery agent about a lost private key, some level of verification should be performed. First, the key recovery agent must make sure that the user is who he or she claims to be. Second, the agent needs to identify the certificate whose accompanying key has been lost.
To retrieve an archived key, the key recovery agent must know one of the following: the certificate common name, the serial number, the SHA-1 hash, or the requester’s name or UPN. Some of these items of information will identify more than one certificate. For example, both the requester’s name and UPN can map to multiple certificates. To identify certificates belonging to a particular user and to obtain unique identifiers, the key recovery agent can use the Certification Authority snap-in to view Issued Certificates. You can identify certificates for which keys have been archived by selecting Add/Remove Columns from the View menu and adding Key Recovery Agent Hash to the list of columns displayed. The Key Recovery Agent Hash column will be populated for those certificates whose private keys have been archived.
The simplest method of recovering the private key for a certificate is to use the certutil.exe command with the -GetKey option. For example, if the serial number for the certificate is 118b237e000000000006, the following command will retrieve and save the private key in an encrypted form in the file named recoveredkey:
certutil -GetKey
118b237e000000000006
recoveredkey
The certutil.exe command also performs the necessary decryption for the recovered key. The following command will save the key in a PKCS#12 file named recover.pfx and protect the file with a password for which the key recovery agent running certutil.exe is prompted twice:
certutil -RecoverKey
recoveredkey recover.pfx
The key recovery agent can send the PKCS#12 file to the user and import the file into the user’s certificate store by launching the Certificate Import Wizard. The recovery agent types the filename at the command line or double-clicks the file in Windows Explorer. To successfully import the certificate, the key recovery agent must communicate the password selected (e.g., by phone) to protect the PKCS#12 file.
Archiving and recovering private keys is a security function, one that you can and should audit. I recommend periodically reviewing audit logs for key recovery agent operations and matching them to user requests. You’ll need to build a process to support the necessary auditing. To generate audit events of archival and recovery operations, right-click the CA in the Certification Authority snap-in, select Properties, click the Auditing tab, and select Store and retrieve archived keys. As key archival and recovery operations take place, details are written to the Security log.
Register
