You can use .NET Server's Version 2 certificate templates to define policy restriction rules for user, machine, subordinate CA, and service certificates. (For more information about Version 2 certificate templates, see the sidebar "Version 2 Certificate Templates," page 52.) You must define all policy restrictions for cross-certification certificates through the capolicy.inf file.
Key Recovery and Archival Methods
Key recovery is a PKI's ability to recover lost or unavailable private encryption keys. As such, successful key recovery requires an efficient and secure key-archival system. Data recovery usually follows key recovery: After a user or authorized administrator gains access to the user's private key, the user or administrator can use the key to decrypt the encrypted symmetric keys with which the user encrypted persistent mail or file data.
Earlier Windows versions provide key recovery for two applications: the Encrypting File System (EFS) and the Secure MIME (S/MIME)—based secure mail application that ships with Microsoft Exchange Server. These applications use slightly different key-archival mechanisms: EFS stores the keys and encrypted file in NTFS, whereas Exchange uses a central key database. The .NET Server PKI builds on the central-database concept, providing a centralized key recovery service that any PKI-enabled application can use.
The .NET Server CA stores key-recovery data locally, in the CA database. The CA uses a symmetric key to encrypt an archived private key, then uses a key recovery agent's public key to encrypt the symmetric key. (A recovery agent is an account with key-recovery privileges.) The CA stores the encrypted private key in the CA database's RawArchivedKey column, then stores the encrypted symmetric key in the KeyRecoveryHashes column. An administrator can view these columns and the rest of the CA database's schema from the command line. To do so, type
certutil -schema
An administrator's ability to recover private keys from the CA's recovery database depends on possession of a special key recovery agent certificate and private key. Like the Exchange Key Management Service (KMS), which manages the S/MIME key-recovery database, the .NET Server CA can support a "missile-silo" system for key recovery: The CA administrator can require multiple administrator key- recovery certificates to recover a key—a system that provides stronger security.
To configure a CA object's key-recovery settings, open the Microsoft Management Console (MMC) Certification Authority snap-in, open the CA object's Properties dialog box, then go to the Recovery Agents tab, which Figure 1 shows. Select the Archive the key check box to enable key recovery. Specify the number of key recovery agents you want to set up in the Number of recovery agents to use text box. Finally, select the accounts you want to use as key recovery agents (these accounts must have a key-recovery certificate and private key).
A full .NET Server CA key-recovery sequence consists of four steps. These steps are as follows:
- The key recovery agent writes down the user principal name (UPN) or serial number of the user certificate whose private key the agent wants to recover.
- To export the recovery data from the CA database, the key recovery agent opens a command prompt and types
certutil -getkey <serial number
or UPN> <output file>
- To transform the output file to a PKCS #12 file (which will contain the recovered private key), the agent types
certutil -recoverkey <output file> <pkcs12 file>
- The agent provides the PKCS #12 file to the appropriate user, who then can import it to his or her certificate store.
You can use the Certificate Templates snap-in to enable key archival at the certificate-template level. To automatically archive the private key when a user requests a certificate based on a particular template, open the template, go to the Request Handling tab, and select the Archive subject's encryption private key check box. You can set the key-archival option only on Version 2 certificate templates.
