Implementing Key Archival Walkthrough

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

The first step in enabling key archival on a CA is enrolling for one or more KRA certificates.

Enrolling a Key Recovery Agent

The first step is to enroll KRAs for KRA Certificates. The following section explains the steps for enrolling a KRA.

Configuring the Certificate Templates

A certificate template suitable for creating KRA certificates is installed in Active Directory. By default, only an Enterprise Administrator or a Domain Administrator may request a KRA certificate as defined by the default ACLs on the KRA certificate template. The certificate template ACLs can be viewed in the Certificate Templates MMC snap-in; in addition, using the Certificate Templates MMC snap-In, certificate templates can be cloned or edited.

To configure a certificate template

1. Log on as an Enterprise or Domain Administrator to the CA machine.

2. Click the Start button, click Run, and then type certtmpl.msc.

3. Click OK.

   Figure 15:  Certificate Templates MMC Snap-In

4. In the details pane, double-click Key Recovery Agent.

5. In the Key Recovery Agent Properties dialog box, click the Security tab.

   Figure 16:  Key Recovery Agent Template Properties

6. Add the appropriate user(s) or group(s) with both Read and Enroll permission.

7. Click OK to close the dialog box.

Next, the Certification Authority must be configured to issue this type of certificate.

Certificate Template Permissions

For a user or a computer to enroll for a certificate template, it must have appropriate permissions [access control entries (ACEs)] set on the template in Active Directory. A user or computer must have both Enroll and Read permissions to enroll for a selected certificate template. The Read permission allows the template to be discovered by the user and the Enroll permission is enforced by the enterprise CA when a user requests a certificate for a selected template. The enterprise CA must also have Read permissions on a template to enumerate the template in the directory and issue certificates based on that template. Normally, the enterprise CA is included in the Authenticated Users group, which has Read permissions by default on a template.

The Full Control permission is given to Enterprise Administrators by default on installation of a fresh Windows Server 2003 domain. If a domain has been upgraded from Windows 2000, Enterprise Administrators will not have this permission by default and the Full Control permission allows a user to set or modify the permissions on a selected template.

The Autoenroll permission is set on a template when a user or computer wants to automatically enroll for a selected certificate template. The Autoenroll permission is needed in addition to the Enroll permission for a user to enroll for a given certificate template.

The Write permission allows a user to modify the contents of a certificate template. Note that only a version 2 certificate with a Windows Server 2003 schema may be modified and version 1 certificate templates may only have the ACLs modified.

Smart Card Support

Smart cards are supported for use in conjunction with KRA certificates. It may be necessary to use a smart card and CSP that supports at least an 8-KB smart card to enroll for a KRA certificate on a smart card. If a smart card does not have adequate memory to support a KRA certificate, the following error will be generated on enrollment.

Error: 0x80100028

An attempt was made to write more data than would fit in the target object

All recovery operations are supported using a Smartcard. The system will prompt the recovery agent to insert an appropriate Smartcard when the key is needed to decrypt the recovery BLOB.

Configuring an Enterprise CA to Issue KRA Certificates

An Enterprise CA must be configured to issue a KRA certificate.

To configure an EnterpriseCA to issue a KRA certificate

1. On the Administrative Tools menu, open the Certification Authority snap-in.

2. In the console tree, expand Certification Authority, and then click Certificate Templates.

3. Right-click the Certificate Templates node, click New, and then click Certificate Template to Issue.

4. In the Select Certificate Template dialog box, click Key Recovery Agent, and then click OK.

5. Close the Certification Authority MMC snap-in.

6. The last manual step is to add the Certification Authority machine account to the Pre-Win2K Compatible Access group in every domain in which users will be using key archival. If this mandatory step is not performed, a CA Officer may not be able to manage groups of users. The Pre-Win2K Compatible Access group allows the CA to enumerate a user account and determine the group membership for CA Manager’s capability.

Enrolling a User with a KRA Certificate

A user may enroll for a certificate with a CA by using the Certificates MMC snap-in or through the CA Web pages. In the case of the KRA template, the template is marked to be “pended” by the CA, which requires that the certificate request be approved first by a CA Administrator or a Certificate Manager before it is issued. Pended certificate requests may only be retrieved through the Web enrollment interface or through the auto-enrollment process. For more information, see Appendix B: Additional Information.

KRA Web Enrollment

To enroll through a Web page

1. Connect to the CA using a Web URL, for example:

   https://<CA Machine Name>/Certsrv

   Note

Note
The Microsoft Certification Authority uses an ActiveX control known as xenroll.dll, which can be downloaded to client browsers that support ActiveX controls. Windows XP and Windows Server 2003 clients both ship with the ActiveX control pre-installed.

</div></td>
</tr>
</tbody>
</table>

A Web site will open allowing you to request a certificate.  
  

2. Select Request a Certificate.

3. On the next Web page, select Advanced Certificate Request.

4. Select Create and submit a request to this CA.

5. The next page will allow the user to select various configuration options, including the type of certificate to request. Choose Key Recovery Agent as the Certificate Template.

   Warning

Caution
A key size of 8192 or larger may take several hours to generate on the client. (Key pairs are always generated by the client CSP, not the CA.) This may slow public key operations on the CA when keys are archived. Key sizes of 2048 are much more reasonable for standard security needs; a key size of 8192 is used only as an example.

</div></td>
</tr>
</tbody>
</table>

The keys should be marked as exportable. This will enable an administrator (KRA) to export the private keys from the local store of the workstation to a disk or other medium for safe storage. Strong private key protection is also recommended, as this will require a password to be used when accessing the private key.  
  

6. When finished, click Submit.

   The Web page will show that the request is being generated. When the key generation and request is complete, if the request had included Enable strong private key protection, a dialog box will appear showing that a protected item is being created (KRA private key).

   Figure 17:  Private Key Security Level Dialog Box

   The dialog box will present the opportunity to set the security level on the private key. If the workstation will be used for KRA operations and the private key is to be kept in the protected store, it is recommended that the security level be set to High. This will ensure that access to the private key will require a separate password.

   Figure 18:  Private Key Security Level Dialog Box

7. Click Next.

   Figure 19:  Private Key Security Level Dialog Box

8. Choose a password, confirm it, and then click Finish.

   Figure 20:  Private Key Security Level Dialog Box

9. Click OK to confirm. The Web page will appear and offer a link to install the certificate. If the Certification Authority is configured to set all certificate requests to pending, the user will have to return to the Web link to install the certificate after the CA administrator or a CA Officer has approved the request.

   Important

Important

The user may have to return to the Web link using the same machine that was used to generate the request. This is due to the fact that certificate pending information is stored as a browser cookie. If auto-enrollment is enabled in Active Directory for the user, the user will not be required to actually return to the Web page. The auto-enrollment process will automatically retrieve the certificate for the user when available. For more information about the auto-enrollment process, see the Certificate Auto-Enrollment in Windows XP white paper in Appendix B: Additional Information.

</div></td>
</tr>
</tbody>
</table>



> [!IMPORTANT]
> <DIV class=alert>

Important
If the issuing CA is in a hierarchy, a second option will appear on the Web page to download the entire path (certificate chain). You should choose to download the entire chain.

</div></td>
</tr>
</tbody>
</table>

The default KRA certificate template requires that the certificate request be pended and not issued automatically. When a certificate request is pended, a CA Officer (Certificate Manager) must manually issue the certificate, assuming that the request was valid. Pending certificate requests can be issued through the Certification Authority MMC and by selecting the pending request node.

The Certificate Manager (or administrator of the server, if role separation is not enabled) can right-click the certificate request and choose to issue or deny the request. For more information about Certificate Managers, see Configuring Certificate Managers.

After the certificate has been issued, the user (KRA) can return to the Web pages to retrieve the pending request.

The user should select View the status of a pending certificate request.

The Web page will display all the pending requests for that user that have been requested from that machine. As mentioned previously, this is managed through Web browser cookies. The user should select the appropriate certificate.

The last page allows the user to install the selected certificate and private key into the local MY store of the user.

Configuring the CA to Allow Key Archival

This section details the steps required to configure the CA to allow key archival.

Note: If the Certification Authority is enabled to enforce role separation, only a CA Administrator may configure KRAs on a CA. Role separation is enabled through the registry and only a local server administrator may configure the registry. The easiest way to enable the CA for role separation is to use the certutil.exe command-line tool:

certutil -setreg ca\RoleSeparationEnabled 1

It is necessary to stop and start certificate services for the setting to take affect.

Enabling a Key Recovery Agent

To enable a KRA

1. Log on as Administrator of the server or CA Administrator, if role separation is enabled.

2. On the Administrative Tools menu, open Certification Authority.

3. In the console tree, select the CA.

4. Right-click the CA name, and then click Properties.

5. Click the Recovery Agents tab.

   Figure 21:  Recovery Agents Tab

6. To enable key archival, click Archive the key.

7. By default, the CA will only use one KRA. However, a KRA certificate must first be selected for the CA to begin archival. To select a KRA certificate, click Add.

   The system will find valid KRA certificates and display the available KRA certificates.

   KRA certificates are normally published to Active Directory by an Enterprise CA when enrollment occurs. KRA certificates are stored under the KRA container in the Public Key Services branch of the configuration partition in Active Directory. Since a CA may issue multiple KRA certificates, each KRA certificate will be added to the multi-valued userAttribute attribute of the CA object.

8. Select one certificate and click OK. You may view the highlighted certificate to ensure that you have selected the intended certificate.

   Figure 22:   Recovery Agents Tab

9. After one or more KRA certificates have been added, click OK to enable key archival on the CA. However, Certificate Services must be stopped and started to enable the use of the selected KRAs. KRA certificates are only processed at service start.

Configuring Certificate Managers

To recover the private keys of a user, the CA enforces that a person be a Certificate Manager (if defined) and also holds a private key for a valid KRA certificate. As a best practice, most organizations separate these two roles. By default, the CA Administrator is a Certificate Manager for all users unless otherwise explicitly defined. A KRA is not necessarily a CA Officer (Certificate Manager). They may be segmented as separate roles. A KRA is defined as a person who holds a private key for a valid KRA certificate.

A CA Officer is defined as a Certificate Manager who has the security permission on the CA to Issue and Manage Certificates. The security permissions are configured on a CA using the Security tab on the CA Properties in the Certification Authority MMC snap-in.

Figure 23:   Security Tab

A CA Administrator can define more specific CA Officer Roles on a Certification Authority by using the Certificate Managers Restrictions tab. By default, any user or group that has the permission to Issue and Manage Certificates is also a CA Officer and can issue, revoke, or export a recovery BLOB for any other user who has been issued a certificate from that CA.  

Figure 24:   Certificate Managers Restrictions Tab

A CA Administrator can define that individual CA Officers have the ability to issue, revoke, and recover certificates for defined sets of user(s) and group(s) by selecting the Restrict certificate managers option. Once the option has been selected, a CA Administrator may define CA Officers’ roles as required.

Configuring User Templates

To enable a user template for key archival, select the template that should enforce key archival and select the Archive subject’s encryption private key check box. Once the check box has been selected, the CA will always enforce key archival for that template.

Figure 25:   Request Handling Tab