Administrator's Guide
Red Hat Certificate System                                                            
Previous
 Contents
 Index
 Next

Chapter 6  

Data Recovery Manager

When data is stored in encrypted form, you must have the private key that corresponds to the public key that was used to encrypt the data in order to decrypt and read it. If the private key is lost, the data cannot be retrieved. A private key can be lost because of a hardware failure, for example, or because the key's owner forgets the password or loses the hardware token in which the key is stored. Similarly, encrypted data cannot be retrieved if the owner of the key is unavailable to supply it-for example, has left the organization that owns the data.

This chapter explains how to use the Data Recovery Manager to archive end-entity's encryption private keys and how to use the archived keys later, in place of missing encryption keys, to recover encrypted data.

This chapter contains the following sections:

PKI Setup for Key Archival and Recovery

To be able to archive end-entity's' encryption private keys and recover them later, you need a PKI setup that includes the following elements:

The sections that follow explain these elements in detail. For step-by-step instructions on setting up your PKI environment for key archival and recovery, see "Installing a Standalone Data Recovery Manager" on page 203.

Clients That Can Generate Dual Key Pairs

Only keys that are used exclusively for encrypting data should be archived; signing keys in particular should never be archived. Having two copies of a signing key would defeat the certainty with which the key identifies its owner; a second archived copy could be used to impersonate the digital identity of the original key owner.

Clients that generate single key pairs use the same private key for both signing and encrypting data, so you cannot archive and recover a private key deriving from a single key pair. By contrast, clients that can generate dual key pairs use one private key for encrypting data and the other for signing data. Because the encryption private key is separate, you can archive it.

In addition to generating dual key pairs, your end-entity's clients must also support the encryption key archival option in certificate requests. This option triggers the key archival process at the time encryption private keys are generated as a part of certificate issuance.

Versions 6.2 and 7.0 or higher support generation of dual key-pairs.

Data Recovery Manager

With the Data Recovery Manager, you can archive end-entity encryption keys when they are created during dual key-pair generation. You can then recover the keys if they are lost or the key owner is unavailable.

The Data Recovery Manager can archive and recover keys only from clients that support dual key-pair generation and the key archival option in certificate requests.

CS does not provide any policy plug-in modules for the Data Recovery Manager. However, you can write custom policy plug-in modules (that is, write Java classes that implement these rules), register them in the Data Recovery Manager's policy framework, and create policy rules using these plug-in implementations. For details about writing custom plug-ins see the CS SDK.

Forms for Users and Key Recovery Agents

End-entity's encryption private keys are archived by the Data Recovery Manager when they are generated. So, for key archival to occur, the enrollment form that users fill out to request dual certificates must have the JavaScript code for activating the key archival option embedded in it, along with a valid copy of the Data Recovery Manager's transport certificate. Then, when a Certificate Manager or Registration Manager that is processing the end-entity's certificate issuance request detects the key archival option, it automatically requests the service of the Data Recovery Manager. For information on customizing this form, see "Step C. Customize the Certificate Enrollment Form" on page 219.

Initiating the key recovery process also requires its own HTML form. By default, the Data Recovery Manager Agent Services interface provides a form for initiating the process and retrieving keys. For information on customizing this form, see "Step D. Customize the Key Recovery Form" on page 225.

Key Archival Process

If your certificate infrastructure has been set up for key archival, the Data Recovery Manager automatically archives end-entity's encryption private keys. For general information on the type of PKI setup needed for archiving keys, see "PKI Setup for Key Archival and Recovery" on page 187. For specific instructions on setting up a key archival and recovery infrastructure, see "Installing a Standalone Data Recovery Manager" on page 203.

Why You Should Archive Keys

If a end-entity's loses a private data-encryption key or is unavailable to use his or her private key, the key must be recovered before any data that was encrypted with the corresponding public key can be read. You can recover the private key if an archival copy of it was created when the key was generated.

Here are a few situations in which you might need to recover a end-entity's encryption private key:

Where the Keys are Stored

If configured properly, the Data Recovery Manager, stores your end-entity's encryption private keys automatically whenever the associated or connected Registration Manager or Certificate Manager issues certificates to your users. The Data Recovery Manager stores encryption private keys in a secure key repository in its internal database; each key is stored as a key record.

The archived copy of the key remains encrypted (or wrapped) with the Data Recovery Manager's storage key; see "Data Recovery Manager's Key Pairs and Certificates" on page 203. It can be decrypted (or unwrapped) only by using the corresponding private key, to which no individual has direct access. A combination of one or more key recovery agents' passwords enables the Data Recovery Manager to retrieve its private storage key and use it to decrypt and recover an archived key. For details on how this process works, see "Key Recovery Agents and Their Passwords" on page 193.

The Data Recovery Manager indexes stored keys by key number (or ID), owner name, and a hash of the public key, allowing for highly efficient searching by name or by public key. The key recovery agents have the privilege to insert, delete, and search for key records. The search feature works like this:

How Key Archival Works

When a Certificate Manager or Registration Manager receives a certificate request that contains the key archival option, it automatically forwards the request to the Data Recovery Manager to archive the end-entity's encryption private key. The Data Recovery Manager receives an encrypted copy of the end-entity's private key and stores the key in its key repository. To archive the key, the Data Recovery Manager uses two special key pairs:

Figure 6-1 illustrates how the key archival process occurs when an end-entity's requests a certificate. The deployment scenario shown in this figure has a Registration Manager acting as the trusted enrollment authority to a Certificate Manager and Data Recovery Manager.

Figure 6-1 How the key archival process works

These are the steps shown in Figure 6-1:

  1. A end entity uses a client capable of generating dual key pairs to access the certificate enrollment form served by the Registration Manager, fills in all the information, and submits the request.
The client detects the JavaScript option and exports only the end-entity's encryption private key, not the signing private key.
The Registration Manager detects the key archival option in the end-entity's request and asks the client for the end-entity's encryption private key.
The client encrypts the end-entity's encryption private key with the public key from the Data Recovery Manager's transport certificate; a copy of the transport certificate is embedded in the enrollment form.
  1. Upon receiving the encrypted key from the client, the Registration Manager sends it to the Data Recovery Manager for storage, along with some other information (including the end-entity's public key). Then, the Registration Manager waits for verification from the Data Recovery Manager that the private key has been received and stored and that it corresponds to the end-entity's public encryption key.
  2. Upon receiving the encrypted key from the Registration Manager, the Data Recovery Manager decrypts it with the private key that corresponds to the public key in its transport certificate. After confirming that the private encryption key corresponds to the end-entity's public encryption key, the Data Recovery Manager encrypts it again with its storage key before storing it in its internal database. (The storage key either resides in a software or a hardware token and is never exposed to any other entity.)
  3. Once the end-entity's private encryption key has been successfully stored, the Data Recovery Manager uses the private key of its transport key pair to sign a token confirming that the key has been successfully stored; the Data Recovery Manager then sends the token to the Registration Manager.
  4. After the Registration Manager receives and verifies the signed token, it sends the certificate request to the Certificate Manager for issuance.
  5. The Certificate Manager formulates two certificates, one each for signing and encryption key pairs, and returns them to the Registration Manager.
  6. The Registration Manager forwards the certificates to the client (the end entity).

Note that all three subsystems subject the request to configured policy rules at appropriate stages. If the request fails to meet any of the policy rules, the subsystem rejects the request.

Key Recovery Process

The Data Recovery Manager supports agent-initiated key recovery. In this method of key recovery, designated recovery agents use the Key Recovery form provided in the Data Recovery Manager Agent Services interface to process key recovery requests, list archived keys, and approve recovery. With the approval of a specified number of agents, an organization can recover keys when the key's owner is unavailable or when keys have been lost.

Key Recovery Agents and Their Passwords

Key recovery agents have the authority to retrieve end-entity's encryption private keys. The recovery agent's role can be performed by any person in your organization. As system administrator, you can designate one or more individuals to be key recovery agents. These individuals need to do the following:

The first time you create key recovery agents and specify their passwords is during the installation of the Data Recovery Manager. However, you can change the number of recovery agents and their passwords later by modifying it in the Data Recovery Manager configuration; see "Changing Key Recovery Agents' Passwords" on page 201.

Secret Sharing of Storage Key Password

The Data Recovery Manager uses the private key of its storage key pair to encrypt the end-entity's encryption private keys. This requires that the storage key be well protected. For the protection of the storage key pair, the Data Recovery Manager supports a password-splitting mechanism called m of n secret splitting or sharing, whereby it splits the PIN that protects the token in which the storage key pair resides among n number of key recovery agents and reconstructs the PIN only if m number of recovery agents provide their individual passwords; n must be an integer greater than 1 and m must be an integer less than or equal to n.

Here's how the m of n secret splitting mechanism gets built and works:

During the installation of a Data Recovery Manager, you generate the storage key pair and specify the hardware token in which the key pair is to be stored. At this time, the system generates a PIN and splits it into n pieces to protect the token, the total number of key recovery agents (n), and how many of these agents (m) are required to perform a key recovery operation. You can change the m of n secret splitting later; for details, see "Key Recovery Agent Scheme" on page 198.

The Data Recovery Manager splits the PIN for the token into n parts or pieces by using the Bloom/Shamir secret-sharing algorithm. It then encrypts these parts with the passwords that are provided by the authorized key recovery agents.

During the key recovery procedure, the required number of key recovery agents (m) provide their identifiers and passwords. After verifying the passwords, the Data Recovery Manager reconstructs the PIN for the token based on the given information.

Interface for the Key Recovery Process

With the Key Recovery form provided in the Data Recovery Manager Agent Services interface, key recovery agents can collectively unlock the storage key of the Data Recovery Manager and retrieve end-entity's encryption private keys and associated certificates in a PKCS #12 package, which can then be imported into the client. For an overview of this process, see "How Agent-Initiated Key Recovery Works" on page 195.

Because key recovery agents use the Data Recovery Manager Agent Services interface, agent-initiated key recovery invariably involves the Data Recovery Manager agent and key recovery agents. The Data Recovery Manager agent's certificate is required to access the Key Recovery form, and key recovery agents' passwords are required to unlock the key repository. For information on Data Recovery Manager agents, see "Agents" on page 316.

Your organization's PKI policy may require that the key recovery process be restricted to authorized recovery agents only, preventing any Data Recovery Manager agent from being involved. If so, you should ask all key recovery agents to get client certificates and set them up as Data Recovery Manager agents. For instructions, see "Setting up Administrators, Agents, and Auditors" on page 318.

Local Versus Remote Key Recovery Authorization

Key recovery agents can authorize the recovery of a key locally or remotely. The overview of local and remote authorization provided in this section is intended to help you determine which to use for your organization. You may find it useful to take a look at the Data Recovery Manager agent-specific information in the CS Agent's Guide.

Local Key Recovery Authorization

To initiate key recovery locally, the required number of recovery agents assemble in front of the host system that allows them to access the Data Recovery Manager Agent Services interface. Either a Data Recovery Manager agent or a key recovery agent with a Data Recovery Manager agent certificate accesses the Key Recovery form hosted by the Data Recovery Manager and initiates the key recovery process. All key recovery agents enter their IDs and passwords on the same Recovery Authorization form presented by the Data Recovery Manager. If the information presented is correct, the Data Recovery Manager retrieves the requested key and returns it along with the corresponding certificate in the form of a PKCS #12 package.

By default, key recovery authorization is local.

Remote Key Recovery Authorization

To authorize key recovery remotely, the required number of recovery agents access the Data Recovery Manager Agent Services interface at their own locations and use the Authorize Recovery button to enter each authorization separately.

Before key recovery agents can authorize key recovery remotely, they must be set up to function as Data Recovery Manager agents. This role gives them the privilege to access the Data Recovery Manager's Agent Services interface directly.

In remote key recovery authorization, one of the key recovery agents informs all required recovery agents about an impending remote key recovery process. All recovery agents access the Key Recovery page hosted by the Data Recovery Manager. One of the agents initiates the key recovery process. The Data Recovery Manager returns a notification to each agent. The notification includes a recovery authorization reference number identifying the particular key recovery request that the agent is required to authorize. Each agent uses the reference number and authorizes key recovery separately.

The Data Recovery Manager informs the agent who initiated the key recovery process of the status of the authorizations. When all of the authorizations are entered, the Data Recovery Manager checks the information. If the information presented is correct, it retrieves the requested key and returns it along with the corresponding certificate in the form of a PKCS #12 package to the agent who initiated the key recovery process.

Key recovery agents can switch to remote authorization by deselecting the local authorization option in the Key Recovery form.

How Agent-Initiated Key Recovery Works

In an agent-initiated key recovery, the key is recovered by the collective efforts of a Data Recovery Manager agent and authorized key recovery agents. You may need to resort to this type of key recovery if the owner of a key cannot be reached and the authorities in the organization need to access that end-entity's encrypted data (for example, S/MIME mail messages).

Upon retrieving the private encryption key (in the form of a PKCS #12 package), the agents may forward the key to the original end entity, the manager of the original owner, or some other authorities. The key (PKCS#12 package) can then be imported into the application for usage.

Figure 6-2 illustrates how agent-initiated key recovery works.

Figure 6-2 The agent-initiated key recovery process

These are the steps shown in Figure 6-2:

  1. The Data Recovery Manager agent accesses the Key Recovery form using the appropriate client certificate, types the identification information pertaining to the person whose encryption private key needs to be recovered, and submits the request.
The request is submitted to the Data Recovery Manager over HTTPS.
  1. The Data Recovery Manager subjects the key recovery request to its policy checks.
  2. If the request passes all the policy rules, the Data Recovery Manager sends a confirmation HTML page to the web browser the agent used. If the request fails any of the policy checks, the server logs an appropriate error message.
The confirmation page contains information and input sections:
    The Data Recovery Manager uses the certificate to construct the
    PKCS #12 package (which includes the end-entity's encryption private key and corresponding certificate), the PKCS #12 password to encrypt the PKCS #12 package, and key recovery agents' passwords to construct the PIN required to unlock its key repository.
  1. The key recovery agents verify the information in the confirmation page and enter the certificate in MIME-64 format, the password for the PKCS #12 package, and their individual identifiers and passwords. The Data Recovery Manager agent submits the page to the Data Recovery Manager.
  2. The Data Recovery Manager matches the key recovery agent information with its m of n scheme (see "Key Recovery Agent Scheme" on page 198). After verifying that the required number of recovery agents entered their passwords, the server uses the agents' passwords to construct the PIN required to access the private key repository.
  3. The Data Recovery Manager then retrieves the end-entity's private key from its key repository and decrypts it by using the private component of the storage key pair.
  4. The Data Recovery Manager packages the end-entity's certificate and the corresponding private key as a PKCS #12 package and encrypts it with the PKCS #12 password provided by the recovery agent. It then delivers the package to the client the recovery agent used to initiate the key recovery process, and prompts the agent to store the encrypted package. The agent may choose to store the package in the local file system of the client machine (only if it has restricted access) or on a floppy diskette.
The recovery agent can then send the encrypted PKCS #12 package and the corresponding password to an individual by any secure, out-of-band means.
Caution

The PKCS #12 package contains the private key. To minimize the risk of key compromise, the recovery agent must use any secure, out-of-band means to deliver the PKCS #12 package and password to the key recipient. As an administrator, you should recommend the recovery agent to use a good password for encrypting the PKCS #12 package, and also consider setting up an appropriate delivery mechanism.


Key Recovery Agent Scheme

The key recovery agent scheme consists of configuring the Data Recovery Manager to recognize a fixed number of key recovery agents (a minimum of one) and specifying how many of these agents are required to authorize a key recovery request before the archived key is restored. Each recovery agent provides the Data Recovery Manager with a password, which it uses to generate a unique PIN; the Data Recovery Manager uses the PIN to protect its storage key pair, which in turn protects end-entity's keys.

The Data Recovery Manager tracks the key recovery agent password for each agent and allows you to facilitate changing agents' passwords; you do not have direct access to these passwords or the actual storage key password. Each password retrieves only a part of the private storage key.

You first specified the key recovery agent scheme when you installed the Data Recovery Manager.

Changing the Key Recovery Agent Scheme

You can change the total number of key recovery agents for a Data Recovery Manager and the number of key recovery agents required to retrieve an end-entity's encryption private key from the Data Recovery Manager's key repository.

To change the key recovery agent scheme:

  1. Access the CS window (see "Logging Into the CS Console" on page 239).
  2. Click the Configuration tab.
  3. In the navigation tree, select the Data Recovery Manager, and in the right pane, click the Scheme Management tab.
The Scheme Management tab shows the current key recovery scheme.


  1. Click Change scheme.
The Change Recovery Key Scheme window appears.


  1. In the New Scheme section, make the appropriate changes:
Number of recovery agents required. Type the number of agents required to authorize a key recovery process. The number cannot be zero and must be equal to or less than the total number of recovery agents.
Total number of recovery agents. Specify the total number of key recovery agents. The number cannot be less than one and must be equal to or greater than the number of agents required to authorize the key recovery operation.
  1. Click Next.
  2. For each agent, enter a user name and password, then click Next.
The number of screens depends on the total number of agents you have specified.
  1. When you have entered all agent information, click Done.
You are returned to the Scheme Management tab.

Changing Key Recovery Agents' Passwords

As administrator, you have the responsibility of safeguarding the security of each Data Recovery Manager installed in your PKI setup. One of the safety measures you can implement is to ask your key recovery agents to change their passwords periodically. This way, you will be sure that the required number of agents are available if a key needs to be recovered. If key recovery agents routinely change their passwords, they are less likely to forget them.

The CS window allows you to view the list of currently designated key recover agents and, if necessary, change an agent's password.

To change key recovery agents' passwords:

  1. Access the CS window (see "Logging Into the CS Console" on page 239).
  2. Click the Configuration tab.
  3. In the navigation tree, select the Data Recovery Manager, and in the right pane, click the Recovery Agent Password tab.
The tab shows current key recovery agents in the Available Agents list.

  1. Select the agent whose password needs to be changed, and click Change Password.
The Change Password dialog box appears.


  1. Allow the agent to enter the appropriate information.
During installation, the Data Recovery Manager prompts you to enter key recovery agent passwords (by default, they are set to agent<n>, where <n> can be 1, 2, and so on, depending on the number of agents). The number of passwords you must enter depends on the key recovery agent scheme you chose; for details, see "Key Recovery Agent Scheme" on page 198. If you are changing a password for the first time after installation, in the "Old password" field you must enter the recovery agent password you specified during installation. Then in the remaining fields, allow the key recovery agent to enter the new password information. If you have more than one key recovery agent, repeat this procedure for all the agents.
Old Password. Type the current password for the key repository.
New Password. Type the new password for the key repository.
Confirm Password. Retype the new password exactly as you typed it in the previous field.
  1. Click OK.
You are returned to the Recovery Agent Password tab.

Installing a Standalone Data Recovery Manager

Data Recovery Manager's Key Pairs and Certificates

The Data Recovery Manager uses the following key pairs and certificates:

Transport Key Pair and Certificate

Every Data Recovery Manager you have installed has a Data Recovery Manager transport certificate. The public key of the key pair that is used to generate the transport certificate is used by the client software to encrypt an end-entity's encryption private key before it is sent to the Data Recovery Manager for archival; only those clients capable of generating dual-key pairs (one for signing and one for encryption) use the transport certificate. For more information on how this certificate is used, see "Key Archival Process" on page 189.

The first time you generated this certificate is when you installed the Data Recovery Manager. The default nickname for the certificate is
kraTransportCert cert-<instance_id>, where <instance_id> identifies the CS instance in which the Data Recovery Manager is installed.

The transport certificate was issued by the CA to which you submitted the certificate signing request. You might have submitted the request to the Certificate Manager that is installed in the same instance, internally deployed another CA, or a public CA. To find out the issuer name, follow the instructions in "Viewing and Deleting Certificate Database Content" on page 285.

Storage Key Pair

Every Data Recovery Manager you have installed has a Data Recovery Manager storage key pair. The first time you generated this key pair is when you installed the Data Recovery Manager.

The Data Recovery Manager uses the public component of this key pair to encrypt (or wrap) end-entity's encryption private keys during the key archival operation; it uses the private component to decrypt (or unwrap) the archived key during the recovery operation. That is, the public key is used to encrypt the key repository the server uses to store end-entity's encryption private keys. For more information on how this key pair is used, see Chapter 6, "Data Recovery Manager."

Note that the public component of the storage key pair is not certified; there is no certificate that corresponds to the public key.

Keys encrypted with the storage key can be retrieved only by authorized key recovery agents. For details, see "Key Recovery Agents and Their Passwords" on page 193.

SSL Server Key Pair and Certificate

Every Data Recovery Manager you have installed has at least one SSL server certificate. The first time you generated this certificate is when you installed the Data Recovery Manager. The default nickname for the certificate is
Server-Cert cert-<instance_id>, where <instance_id> identifies the CS instance in which the Data Recovery Manager is installed.

The Data Recovery Manager's SSL server certificate was issued by the CA to which you submitted the certificate signing request. You might have submitted the request to the Certificate Manager that is installed in the same instance, an internally deployed CA, or a public CA. To find out the issuer name, follow the instructions in "Viewing and Deleting Certificate Database Content" on page 285.

The Data Recovery Manager uses its SSL server certificate to do SSL server-side authentication to the following:

By default, the Data Recovery Manager uses a single SSL server certificate for authentication purposes. However, you can request and install additional SSL server certificates for the Data Recovery Manager. For example, you can configure the Data Recovery Manager to use separate server certificates for authenticating to Red Hat Console, the end entity services interface, and the Data Recovery Manager Agent Services interface. For instructions, see "Configuring the Server to Use Separate SSL Server Certificates" on page 310.

Tokens

You choose either the internal token (if you plan to use the internal/software token) or an external token to store the signing certificate and key pair and the SSL signing certificate and key pair.

If you are using an external token, you will need to install it before you run the Installation Wizard. In the wizard, you can select from a list of already installed and available tokens. For example, SmartCard. For installation instructions, see "External Token" on page 306.

Internal Database

Each subsystem uses an internal database to store information (such as certificates and certificate requests) used by the subsystem you will be installing in this CS instance. By default, a separate internal database is created for each subsystem you configure. You can choose to use the same internal database for more than one subsystem by specifying this when running the installation wizard to configure that subsystem. You should carefully consider whether you want to store this information in a separate internal database for each subsystem or use one internal database for all subsystems installed on the host.

It's recommended that you do not use this Directory Server instance for any other purposes; the directory schema will be configured for storing CS data.

Key Type and Length

If you wish, you can import the signing key and certificate used in a previous version of CS installation rather than generating a new signing key pair. For information on how to do this, check the migration information.

If you decide to generate a new signing key, one of the first decisions you need to make is whether to use the RSA or DSA algorithm. If you use DSA, the software can generate and verify the PQG value. PQG values are used to create the DSA signing key pair. For more information about the way they are used, check this document: http://www.itl.nist.gov/div897/pubs/fip186.htm.

In general, longer keys are considered to be cryptographically stronger than shorter keys. However, longer keys also require more time for signing operations. (Certificate Manager CA signing keys up to 2048 bits in length are not subject to export restrictions.)

Many people no longer consider an RSA key of length less than 1024 bits to be cryptographically strong. Export and other regulations permitting, it may be a good rule of thumb to start with 1024 bits and consider increasing the length to 4096 bits for certificates that provide access to highly sensitive data or services. However, the question of key length has no simple answers. Every organization must make its own decision based on its own security requirements. For more information on key length and encryption strength, see Appendix D of Managing Servers with Red Hat Console.

Installing the Data Recovery Manager

To install a standalone Data Recovery Manager:

  1. Log into Red Hat Console as the administrator.
  2. Select the CS instance and then either click Open, or double click this instance.
The Installation Wizard launches.
  1. Installation Wizard Introduction. Click Next to continue.
  2. Logon Token. Enter either internal (if you plan to use the internal/software token) or the name of an external token to store the Certificate Manager signing certificate and key pair. If you have not previously initialized the token's password, you must do so in this screen. See "Tokens," on page 205 for more information.
  3. Internal Database. Choose to either create a new internal database for this instance or to use an existing Directory Server instance as the internal database for this instance. Next, specify the information for that Directory Server instance. See "Internal Database," on page 205 for more information.
Click Next to continue. The wizard sets up the new internal database, which takes some time.
Click Next to continue.
  1. Administrator. Type the user ID, name, and password for the CS administrator. This user ID will be set up as the administrator who can access the CS window and control all CS settings.
Allow Multiple Roles for Users. Select if you want to allow users to belong to more than one group, thus assuming more than one role. Deselect if you want to restrict users from being able to belong to more than one role. This setting only applies to the default administrator, agent, auditor, and trusted manager roles.
Click Next to continue.
  1. Subsystems. Choose a subsystem you want to install.
Select Data Recovery Manager.
Click Next to continue.
  1. Network Configuration. Type the numbers for the ports to be used by the CS instance.
Click Next to continue.
  1. Key-Pair Information for Data Recovery Manager Transport Certificate. Select the token to store the transport certificate and key pair. If you have not previously initialized the token's password, you must do so in this screen. Also specify the key type and length. See "Tokens," on page 205 for more information.
    • Token. Enter either internal (if you plan to use the internal/software token) or the name of an external token to store the transport certificate and key pair. If you have not previously initialized the token's password, you must do so in this screen. See "Tokens," on page 205 for more information.
    • Key Type. Choose RSA or DSA.
    • Key Length. Available key sizes for RSA are 512, 768, 1024, 2048, 4096, or Custom. Available key sizes for DSA are 512, 1024, or Custom (which must be in increments of 64 bits only).
See "Key Type and Length" on page 206 for more information.
Click Next to continue.
  1. Subject Name for Data Recovery Manager Transport Certificate. Type the values for the subject DN components; these values identify the transport certificate.
Click Next to continue.
  1. Certificate Extensions for Data Recovery Manager Transport Certificate. Select the required extensions. The default settings should work for most deployments. If necessary, you can add an additional extension by pasting its base-64 encoding in the space provided on this screen.
CS provides command-line tools for generating extensions to include in CA and other certificate requests. For details about these tools, check this directory: <server_root>/bin/cert/tools
Note that the certificate extension text field accepts a single extension blob. If you want to add multiple extensions, you should use the ExtJoiner program, which is also provided in the tools directory. For details on using the ExtJoiner program, see Chapter 5, "Extension Joiner Tool" of CS Command-Line Tools Guide.
Click Next to continue.
  1. Data Recovery Manager Transport Certificate Request Creation. This informational screen tells you that the wizard has all the information required to generate the key pair and certificate request. In the previous screen, if you chose to include the Subject Key Identifier extension in the certificate, you'll be given the choice to select the format for the certificate request. Otherwise, the request format will be PKCS #10.
    • If you want the wizard to generate the certificate request in PKCS #10 format, select the "Generate PKCS10 request" option.
    • If you want the wizard to generate the certificate request in CMC format, select the "Generate CMC full enrollment request" option.
Click Next. The wizard generates the certificate request that you must submit to a CA, which could be a remote Certificate Manager or a third-party CA.
  1. Submission of Request. Specify whether you want to submit the request automatically or manually.
    • To automatically submit the request to a remote Certificate Manager (or for automatic enrollment), follow these steps:
      1. Select the "Send the request to a remote CS now" option.
      2. Enter the host name and end-entity port number, and specify whether the end-entity port is SSL enabled.
      3. Click Next to submit the request.
The Certificate Request Result screen appears, confirming that the request has been submitted. Note the request ID provided in the response message. (You can use it later to retrieve the certificate, once it has been issued, from the end-entity port.)
Note that your request gets added to the agent queue of the remote Certificate Manager for approval by that Certificate Manager's agent. If you've permission to access that Certificate Manager's Agent interface, you can follow the instructions below to issue the certificate. Otherwise, you should wait for the remote Certificate Manager's agent to approve your request.
Be sure to not make any changes to the certificate. You're required to paste the encoded certificate into the Installation Wizard next. So, once you've copied the certificate, go back to the wizard screen (Step 14).
For example, if you assigned the port number 17006 to the non-SSL end-entity port for your root CA, you would go to the URL http://<hostname>:17006 to bring up the Certificate Manager page for end entities.
In the resulting form, choose the request type from the pull down menu, paste the request into the request field, and fill in the other information in the form.
Be sure to not make any changes to the certificate. You're required to paste the encoded certificate into the Installation Wizard next. So, once you've copied the certificate, go back to the wizard screen (Step 14).
This action copies the certificate request to the clipboard. In addition to the copy on the clipboard, the screen informs you that the certificate request has been saved to a file. You can use either the copy on the clipboard or the copy in the file to transfer your request to the CA that will issue the Data Recovery Manager's transport certificate.
Click Next when you are ready to proceed.
  1. Data Recovery Manager Transport Certificate Installation. Depending on whether you have the certificate ready for pasting into the Installation Wizard screen, click Yes or No.
    • If you have submitted your request to a third-party CA or to a remote Certificate Manager for which you do not have agent privileges, you may have to wait days or weeks before you receive the certificate. In this case, you should click No, continue as far as you can with the configuration, and resume after you receive the certificate. The default is No.
    • Select Yes, only if you have the certificate ready in its base-64 encoded format.
Click Next to continue.
  1. Location of Certificate. Specify the location of the certificate. You can use any of these options:
    • If you copied the encoded certificate to a file, select the "The certificate is located in this file" option and then type the file path, including the filename, in the text field.
    • If you copied the certificate to the clipboard, select the "The certificate is located in the text area below" option and then paste in a base-64 encoded certificate (including the header and footer) in the text area provided.
    • If you noted the request ID of your request and know the host name and end-entity port number of the remote Certificate Manager that issued the certificate, select the "The certificate is at the CS server where the request was sent" option and then specify the required details.
Click Next to continue.
  1. Certificate Details. This informational screen displays the certificate so you can inspect its contents. Notice the nickname assigned to the certificate and verify that you're installing the correct certificate.
Click Next to continue.
  1. Import Certificate Chain. This screen appears only if you need to import the CA certificate chain. Follow these steps to import the CA chain of the remote Certificate Manager:
    1. Go to the web browser window.
    2. Enter the end-entity URL for the remote Certificate Manager that issued the transport certificate.
    3. Select the Retrieval tab, and then in the left-hand frame, click Import CA Certificate Chain.
    4. In the resulting form, select the "Display the CA certificate chain in PKCS#7 for importing into a server" option, and click Submit.
    5. In the resulting page, locate the CA certificate chain in its base-64 encoded format, and copy it to the clipboard.
    6. Return to the Installation Wizard.
    7. Paste the CA certificate chain into the text box.
Click Next to continue.
The screens that follow let you configure the storage key and recovery schemes for the Data Recovery Manager.
  1. Storage Key Creation for Data Recovery Manager. Select the length you have decided on for your storage key.
Click Next to continue.
  1. Data Recovery Key Scheme - 1. Type both the required number of recovery agents and the total number of recovery agents.
Click Next to continue.
  1. Data Recovery Key Scheme - 2. The number of table rows correspond to the total number of agents you specified in the previous screen. Type the user ID and password for each agent in the table.
Click Next to continue. The screens that follow let you request an SSL server certificate for the Data Recovery Manager.
  1. Key-Pair Information for SSL Server Certificate.
    • Token. Enter either internal (if you plan to use the internal/software token) or the name of an external token to store the SSL server and key pair. If you have not previously initialized the token's password, you must do so in this screen. See "Tokens," on page 205 for more information.
    • Key Type. Choose RSA.
    • Key Length. Available key sizes for RSA are 512, 768, 1024, 2048, 4096, or Custom. Available key sizes for DSA are 512, 1024, or Custom (which must be in increments of 64 bits only).
See "Key Type and Length" on page 206 for more information.
Click Next to continue.
  1. Message Digest Algorithm. Select the algorithm to use for computing the certificate signature. The choices are: SHA-1, MD2, or MD5.
Click Next to continue.
  1. Subject Name for SSL Server Certificate. Type the values for the subject DN components; these values the Data Recovery Manager's SSL server certificate. The CN must be the fully-qualified host name of the machine on which you're installing the Data Recovery Manager.
Click Next to continue.
  1. Certificate Extensions for SSL Server Certificate. Select the required extensions. The default settings should work for most deployments. If necessary, you can add an additional extension by pasting its base-64 encoding in the space provided on this screen. (For details, see Step 11 of this section.)
Click Next to continue.
  1. SSL Server Certificate Request Creation. This is an informational screen that tells you that the wizard has all the information required to generate the key pair and certificate request. In the previous screen, if you chose to include the Subject Key Identifier extension in the certificate, you'll be given the choice to select the format for the certificate request. Otherwise, the request format will be PKCS #10.
    • If you want the wizard to generate the certificate request in PKCS #10 format, select the "Generate PKCS10 request" option.
    • If you want the wizard to generate the certificate request in CMC format, select the "Generate CMC full enrollment request" option.
Click Next. The wizard generates a certificate request that you must submit to a CA.
  1. Submission of Request. Select whether you want to submit the request manually or send the request automatically to a remote Certificate Manager.
    • To automatically submit the request to a remote Certificate Manager (or for automatic enrollment), follow these steps:
      1. Select the "Send the request to a remote CS now" option.
      2. Enter the host name and end-entity port number of the remote Certificate Manager, and specify whether the end-entity port is SSL enabled.
      3. Click Next to submit the request.
The Certificate Request Result screen appears, confirming that the request has been submitted. Note the request ID provided in the response message. (You can use it later to retrieve the certificate, once it has been issued, from the end-entity port.)
Note that your request gets added to the agent queue of the remote Certificate Manager for approval by that Certificate Manager's agent. If you've permission to access that Certificate Manager's Agent interface, you can follow the instructions below to issue the certificate. Otherwise, you should wait for the remote Certificate Manager's agent to approve your request and issue the certificate.
Be sure to not make any changes to the certificate. You're required to paste the encoded certificate into the Installation Wizard next. So, once you've copied the certificate, go back to the wizard screen (Step 27).
For example, if you assigned the port number 17006 to the non-SSL end-entity port for your root CA, you would go to the URL http://<hostname>:17006 to bring up the Certificate Manager page for end entities.
In the resulting form, choose the type of request from the pull down menu, paste the request in the request field, and fill in the other fields on the form.
If you used the Manual Server Certificate Enrollment request, the request gets added to the agent queue of that Certificate Manager for approval by that Certificate Manager's agent. If you've permission to access that Certificate Manager's Agent interface, you can follow the instructions below to issue the certificate. Otherwise, you'll have to wait for the Certificate Manager's agent to approve your request and issue the certificate.
To approve the request, do the following:
In the web browser window, enter the URL for the Certificate Manager's Agent Services page. (You must have a valid agent's certificate.)
Select List Requests, then click Show Pending Requests and click Find. The pending request list is displayed.
Locate your request, click Details to see it, and make any changes. Then, scroll down to the bottom of the form, select the appropriate action.
Be sure to not make any changes to the certificate. You're required to paste the encoded certificate into the Installation Wizard next. So, once you've copied the certificate, go back to the wizard screen (Step 27).
This action copies the certificate request to the clipboard. In addition to the copy on the clipboard, the screen informs you that the certificate request has been saved to a file. You can use either the copy on the clipboard or the copy in the file to transfer your request to the CA that will issue the subordinate CA's signing certificate.
Click Next when you are ready to proceed to the next screen.
  1. SSL Server Certificate Installation. Depending on whether you have the certificate ready for pasting into the Installation Wizard screen, click Yes or No.
    • If you have submitted your request to a third-party CA or to a remote Certificate Manager for which you do not have agent privileges, you may have to wait days or weeks before you receive the certificate. In this case, you should click No, continue as far as you can with the configuration, and resume after you receive the certificate. The default is No.
    • Select Yes, only if you have the certificate ready in its base-64 encoded format.
Click Next to continue.
  1. Location of Certificate. Specify the location of the certificate. You can use any of these options:
    • If you copied the encoded certificate to a file, select the "The certificate is located in this file" option and then type the file path, including the filename, in the text field.
    • If you copied the certificate to the clipboard, select the "The certificate is located in the text area below" option and then paste in a base-64 encoded certificate (including the header and footer) in the text area provided.
    • If you noted the request ID of your request and know the host name and end-entity port number of the remote Certificate Manager that issued the certificate, select the "The certificate is at the CS server where the request was sent" option and then specify the required details.
Click Next to continue.
  1. Certificate Details. This is an informational screen that displays the certificate so you can inspect its contents. Notice the nickname assigned to the certificate and verify that you're installing the correct certificate.
Click Next to continue.
  1. Import Certificate Chain. This screen appears only if you need to import the CA certificate chain again. Follow these steps to import the CA chain of a remote Certificate Manager:
    1. Go to the web browser window.
    2. Enter the end-entity URL for the remote Certificate Manager that issued the SSL server certificate.
    3. Select the Retrieval tab, and then in the left-hand frame, select Import CA Certificate Chain.
    4. In the resulting form, select the "Display the CA certificate chain in PKCS#7 for importing into a server" option, and click Submit.
    5. In the resulting page, locate the CA certificate chain in its base-64 encoded format and copy it to the clipboard.
    6. Return to the Installation Wizard.
    7. Paste the CA certificate chain into the text box.
Click Next to continue.
  1. Single Sign-on Summary. Check the summary and select whether to retain or delete the password.conf file.
The single signon password simplifies the way you subsequently sign on to CS by storing the passwords for the internal database, tokens, and so on. Each time you log on, you're only required to enter this single password. (For details, see "System Passwords" on page 244.)
Click Next to continue.
  1. Configuration Status. This screen should indicate that your configuration has been successful.
Click Done to exit the Installation Wizard.
  1. You now need to create the first agent user for the Data Recovery Manager. See "Agent Certificates," on page 324 for details.

Configuring Key Archival and Recovery Process

By default, the Data Recovery Manager is not configured to archive or recover end-entity's encryption private keys. This section explains how to set up key archival and recovery processes.

Step 1. Set Up the Key Archival Process

Before proceeding with this section, you should have read "Key Archival Process" on page 189. In particular, you should be familiar with how the key archival process works. If you are not, see "How Key Archival Works" on page 190.

To set up the key archival process, follow these steps:

Step A. Deploy Clients That Can Generate Dual Key Pairs

You can use the Data Recovery Manager to archive and recover keys only from clients that support dual key-pair generation, the key archival option, and the CMC protocol. Clients that do not meet this criteria cannot be used with the Data Recovery Manager. To understand why you need to use clients that can generate dual key pairs, see "Clients That Can Generate Dual Key Pairs" on page 188. The same section also points you to an introduction to Red Hat Personal Security Manager, which when plugged into Netscape Communicator version 4.7x enables it to support the CMC protocol and generate dual key pairs.

Step B. Connect the Enrollment Authority and the Data Recovery Manager

Key archival occurs when dual key pairs are generated by the client. The client generates the key pairs when a user requests a certificate by filling out the appropriate certificate enrollment form served by an enrollment authority, which can be either a Certificate Manager or a Registration Manager. When the enrollment authority detects the key archival option in the request, it initiates the key archival process and requests the service of the Data Recovery Manager for archiving the key.

For the enrollment authority to be able to request the service of the Data Recovery Manager, the two subsystems must be configured to recognize, trust, and communicate with each other. When you installed the Certificate Manager, you were asked if you wanted to connect it to a Data Recovery Manager. If you did, some of the configuration was done at this time.

However, to ensure that key archival takes place successfully, you must make sure that the Certificate Manager is connected to the Data Recovery Manager. Also verify whether the enrollment authority has been set up as a privileged user, with an appropriate SSL client authentication certificate, in the internal database of the Data Recovery Manager. By default, the Certificate Manager uses its SSL server certificate for SSL client authentication, whereas the Registration Manager uses its signing certificate for this purpose.

Otherwise, follow the instructions in "Setting Up a Trusted Manager" on page 321 and set up the enrollment authority as a trusted front end to the Data Recovery Manager.

Step C. Customize the Certificate Enrollment Form

For the enrollment authority to automatically initiate the key archival process at the time key pairs are generated, a certificate request must include the following information:

Make sure that the transport certificate, in its base-64 encoded format, is embedded in the form. Otherwise, the Data Recovery Manager will fail to archive end-entity's keys.

Note that the JavaScript method includes parameters for specifying various things. You are required to update the following information only:

The steps that follow explain how to do this.

  1. Copy the transport certificate in its base-64 encoded format.
The transport certificate is stored in the Data Recovery Manager's certificate database. If the transport certificate is signed by a Certificate Manager, then a copy of the certificate is also available with the Certificate Manager. Follow the instructions as appropriate.
To copy the transport certificate information from a Certificate Manager's database:
  1. Open a web browser window.
  2. Go to the end-entity page hosted by the Certificate Manager.
  3. Click the Retrieval tab.
  4. List or search for the transport certificate.
  5. Click Details, and view the certificate information.
Make sure that the certificate you are looking at is the correct one; the certificate shows the DN that was specified for the transport certificate during the installation of Data Recovery Manager.
    1. Scroll down to the section that says "Installing this certificate in a server."

    2. Copy the base-64 encoded certificate, excluding the marker lines -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----, to a text file. An example is shown below:
MIICDjCCAXegAwIBAgICAfMwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI0
5ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMREwDwYDVQQLEwhIYXJkY29yZTEnMCUG
A1UEAxMeSGFyZGNvcmUgQ2VydGlmaWNhdGUgU2VydmVyIElJMB4XDTk4MTExOTIzNDIxOVoXDTk5MD
UxODIzNDIxOVowLjELMAkGA1UEBhMCVVMxETAPBgNVBAoTCG5ldHNjYXBlMQwwCgYDVQQDEwNLUmEw
XDANBgkqhkiG9w0BAQEFAANLADBIAkEArrbDiYUI5SCdlCKKa0bEBn1m83kX6bdhytRYNkdHB9
To copy the transport certificate information from a Data Recovery Manager's certificate database:
    1. Open a terminal window in the system that hosts the Data Recovery Manager.
    2. Use the command-line tool called certutil to retrieve the transport certificate from the Data Recovery Manager's certificate database. (For information on the certutil tool, check this site: http://www.mozilla.org/projects/security/pki/nss/tools/
First, go to this directory: <server_root>/cert-<instance_id>/config
Next, run this command: <server_root>/bin/cert/tools/certutil -L
-d . -n kraTransportCert cert-<instance_id> -a
The transport certificate appears. View the certificate information. Make sure that the certificate you are looking at is the correct one; the certificate shows the DN that was specified for the transport certificate during the installation of Data Recovery Manager.
  1. Copy the base-64 encoded certificate, excluding the marker lines -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----, to a text file. The copied information should look like the example below:
MIICDjCCAXegAwIBAgICAfMwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI0
5ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMREwDwYDVQQLEwhIYXJkY29yZTEnMCUG
A1UEAxMeSGFyZGNvcmUgQ2VydGlmaWNhdGUgU2VydmVyIElJMB4XDTk4MTExOTIzNDIxOVoXDTk5MD
UxODIzNDIxOVowLjELMAkGA1UEBhMCVVMxETAPBgNVBAoTCG5ldHNjYXBlMQwwCgYDVQQDEwNLUmEw
XDANBgkqhkiG9w0BAQEFAANLADBIAkEArrbDiYUI5SCdlCKKa0bEBn1m83kX6bdhytRYNkdHB95B
  1. Update the JavaScript method in the enrollment form.
To do this:
    1. Go to the host system of the enrollment authority and locate the user-enrollment form. The default forms are at these locations: <server_root>/cert-<instance_id>/web-apps/ee ca and <server_root>/cert-<instance_id>/web-apps/ee/ra
    2. Open the enrollment form (ProfileSelect.template) that you want to use in a text editor.
    3. In the form, locate the generateCRMFRequest() JavaScript method.
    4. Add a variable for the transport certificate.
Below the commented text, add this line:
var kraTransportCert =
    1. Open the text file that has the Data Recovery Manager's transport certificate (the one you copied earlier) and copy the certificate.
    2. Paste the certificate as the value of the kraTransportCert variable.
Paste the certificate in front of the = sign, remove any line breaks, enclose the certificate within double-quotation marks (""), and end the string with a semicolon (;). When deleting line breaks, be sure not to delete any of the characters in the encoded blob.
An example is shown below:
var kraTransportCert = "MIICDjCCAXegAwIBAgICAfMwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDA
qBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMREwDwYDVQQ
LEwhIYXJkY29yZTEnMCUGA1UEAxMeSGFyZGNvcmUgQ2VydGlmaWNhdGUgU2VydmVyIEl
JMB4XDTk4MTExOTIzNDIxOVoXDTk5MDUxODIzNDIxOVowLjELMAkGA1UEBhMCVVMxETA
PBgNVBAoTCG5ldHNjYXBlMQwwCgYDVQQDEwNLUmEwXDANBgkqhkiG9w0BAQEFAANLADB
IAkEArrbDiYUI5SCdlCKKa0bEBn1m83kX6bdhytRYNkdHB95Bp85SR";
    1. Pass the kraTransportCert variable to the JavaScript method.
Replace null (the fourth line in the method) with kraTransportCert.
    1. Specify the key algorithm and key type (see "generateCRMFRequest()" in Javascript API for Client Certificate Management).
Below is an example that shows how the updated generateCRMFRequest() method would look:
// generate keys for PSM.

if (navigator.appName == "Netscape" && (navMajorVersion() > 3) &&

			typeof(crypto.version) != "undefined") {

			certNickname.value = subject.value;

			crmfObject = crypto.generateCRMFRequest(subject.value,

							"regToken",

							"authenticator",

							kraTransportCert,

							"setCRMFRequest();",

							512, null, "rsa-ex",

							1024, null, "rsa-sign");

}
 
  

    
  The method triggers the client to generate two RSA key pairs-one key of length 512 for encrypting data and another key of length 1024 for signing data.
  

  
    
    
  1.  Save your changes.

Step D. Configure Key Archival Policies

This step is optional.

Unlike Certificate Manager and Registration Manager, no policy plug-in modules are provided for the Data Recovery Manager. If you have implemented any custom policy modules for the Data Recovery Manager's key archival process, you should make sure that they are configured properly. For details on configuring policies for a subsystem, see "Configuring Policy Rules for a Subsystem" on page 471.

Step 2. Set Up the Key Recovery Process

Before proceeding with this section, you should have read "Key Recovery Process" on page 192. In particular, you should be familiar with how the key archival process works. If you are not, see "How Agent-Initiated Key Recovery Works" on page 195.

The Data Recovery Manager supports agent-initiated key recovery process, in which end-entity's encryption private keys are recovered by designated key recovery agents. This section explains how to set up the key recovery process.

To set up agent-initiated key recovery process, follow these steps:

Step A. Verify the m of n Scheme

During the installation of the Data Recovery Manager, you were asked to specify the total number of key recovery agents (a minimum of one) and the number of agents (of this total) required to authorize a key recovery operation. This combination is called m of n scheme. For more information about this, see "Key Recovery Agent Scheme" on page 198.

Verify that the current m of n scheme is appropriate for your PKI setup. If it isn't, change the scheme following the instructions in "Changing the Key Recovery Agent Scheme" on page 198.

Step B. Facilitate the Key Recovery Agents to Change the Passwords

During the installation of Data Recovery Manager, after you specified the m of n scheme, you were also prompted to provide unique passwords for each recovery agent. It is quite likely that you specified these passwords yourself instead of it being done by those individuals who have been designated with the key recovery agents' role in your organization. Therefore, you must get the designated recovery agents to change the passwords entered during installation.

Step C. Determine the Authorization Mode for Key Recovery

The Data Recovery Manager allows key recovery agents to authorize recovery of an end-entity's encryption private key locally or remotely. The default configuration is local authorization. It is important that you evaluate both the authorization modes, and choose the one that is appropriate for your organization. For more information about this, see "Local Versus Remote Key Recovery Authorization" on page 194.

If want the key recovery agents to authorize key recovery remotely, be sure to set them up as Data Recovery Manager agents following the instructions in "Setting up Administrators, Agents, and Auditors" on page 318.

Step D. Customize the Key Recovery Form

Key recovery agents need an appropriate interface to initiate the key recovery process. By default, the Data Recovery Manager's Agent Services interface includes an HTML form (recoverKey.html) that allows key recovery agents to initiate the key recovery process and retrieve end-entity's encryption keys. For details about this form, check CS Customization Guide.

If you want to customize this form to suit your organization, be careful not to delete any of the information that is vital to the functioning of the form; it is recommended that you restrict your changes to the content presented in the form.

Step E. Configure Key Recovery Policies

This step is optional.

Unlike Certificate Manager and Registration Manager, no policy plug-in modules are provided for the Data Recovery Manager. If you have implemented any custom policies for the Data Recovery Manager's key recovery process, you should make sure that they are configured properly. For details on configuring policies for a subsystem, see "Configuring Policy Rules for a Subsystem" on page 471.

Step 3. Test Your Key Archival and Recovery Setup

The steps outlined in this section explain how to verify key archival and recovery process using Netscape Communicator 4.7 with Personal Security Manager, version 1.01.

Step A. Test Your Key Archival Setup

To test whether you can successfully archive a key, follow these instructions.

  1. Enroll for dual certificates.
To do this:
    1. Open a web browser window.
    2. Go to the end-entity interface for the enrollment authority.
The default URL is as follows: https://<hostname>:<end_entity_HTTPS_port> or http://<hostname>:<end_entity_HTTP_port>
    1. In the end-entity interface, open the enrollment form you customized in "Step C. Customize the Certificate Enrollment Form" on page 219.
(Perform a "View Source" to ensure that the browser loads the correct page with the JavaScript method you edited.)
    1. Fill in all the values and submit the request.
The client prompts you to enter the password for your key database.
    1. When you enter the correct password, the client generates the key pairs.
Do not interrupt the key-generation process.
  1. Approve the request.
This step is required only if you used the manual enrollment form for requesting the certificate.
    1. Go to the enrollment authority's Agent Services interface.
The default URL is as follows: https://<hostname>:<agent_port>
    1. Click the link that says List Requests.
    2. In the form that appears, select the "Show pending requests" option and click Find.
You should see your request in the list of pending requests.
    1. Make sure the request has the appropriate extensions set for S/MIME (E-mail bit of the Netscape Certificate Type extension selected) and the subject name contains the email information (the value of the E attribute).
    2. Locate and approve the request.
  1. Check if the certificates have been issued.
To do this:
    1. Click the List Requests link again.
    2. In the form that appears, select the "Show completed requests" option and click Find.
You should see two new certificates with consecutive serial numbers.
    1. Download the certificates to the web browser.
    2. Go to the security information window of the browser (from the Communicator menu, choose Edit, and then choose Tools, and then choose Security Info).
    3. Click Certificates and then click Manage Certificates.
    4. Verify that the test certificates have been stored in the browser's certificate database.
  1. Check whether the key has been archived. To do this:
    1. Go to the Data Recovery Manager's Agent Services interface.
    2. Click the link that says List Requests.
    3. In the form that appears, check the "Show completed requests" option and click Find.
    4. If the key has been archived successfully, you should see the information pertaining to that key. If you don't see the key archived, check the logs and correct the problem before proceeding to the next step.
    5. If the key has been successfully archived, exit the client completely-that is, from the File menu, select Exit; this will close all client windows.

Step B. Verify the Key

To do this:

  1. Open a browser window again.
  2. Open the email client, Messenger, and send a signed and encrypted email to yourself.
  3. When you receive the email, open it, and check the message to see if it is signed and encrypted.
There should be a security icon at the top-right corner of the message window and it should indicate that the message is signed and encrypted.

Step C. Delete the Certificate

To do this:

  1. Open the security information window.
  2. Click Certificates and then click Mine.
  3. In the list of certificates, select the test certificate you downloaded previously and click Delete.
  4. When prompted confirm the delete action.
  5. Check your email again. This time, you should not be able to verify the email message because you have deleted the certificates from the client's certificate database.

Step D. Test Your Key Recovery Setup

To test whether you can successfully recover an archived key:

  1. Go to the Data Recovery Manager's Agent Services interface.
  2. Click the Recover Keys link.
  3. In the form that appears, enter any of the following information for the encryption private key that has been archived:
    • The key owner's name
    • The serial number of the key
    • The public key that corresponds to the private key (in the form of base-64 encoded certificate)
    • The instance ID of the enrollment authority that initiated the key archival process
If you need more information about any of the fields in this form, click the Help button.
  1. Click Show Key.
If the key has been archived successfully, you should see the information pertaining to that key.
  1. Click Recover.
  2. In the form that appears, enter the following information:
    • The PKCS #12 password; the Data Recovery Manager uses this password to encrypt the PKCS #12 package (see "How Agent-Initiated Key Recovery Works" on page 195).
    • The base-64 encoded certificate that corresponds to the private key you want to recover; use the enrollment authority's end-entity or agent interface to get this information. If you searched for the archived key by providing the base-64 encoded certificate in (step 4), then you don't have to provide this information.
    • The key recovery agents' passwords.
  3. Click Recover.
If you entered the correct information, the Data Recovery Manager returns the private key packaged as a PKCS #12 blob (it contains the recovered key pair and the corresponding certificate) and prompts you to save it. Specify the path and filename for saving the encrypted file. Be sure not to change the default file extension (.p12).

Step E. Restore the Key in the Browser's Database

To do this:

  1. Go to the security information window of your browser.
  2. Import the *.p12 file (that you saved in the previous step) back into the browser.
  3. Open the test email that you couldn't verify after deleting the certificate from the browser's certificate database; you should be able to verify it again.



Previous
 Contents
 Index
 Next
© 2001 Sun Microsystems, Inc. Used by permission. © 2005 Red Hat, Inc. All rights reserved.
Read the Full Copyright and Third-Party Acknowledgments.

 last updated September 26, 2005