SECURING


Certificate authority key rollover

HCL Domino® administrators can assign a new set of public and private keys to a Domino certificate authority (CA). These keys are used to certify the keys of OUs, servers, and users in that organization. The process of assigning news keys is known as key rollover.

About this task

Rolling over a CA key may become necessary because:


When an administrator assigns a new set of keys to a Domino CA, new keys are created and self-certified and added to the top-level certifier ID file in the pending key area of the ID file. The keys that were previously in use are added to the archived keys area of the ID file, and rollover certificates binding the new and old keys are added to the rollover certificate area of the ID file.

The time frame in which the new keys are created and old ones archived differ with the method used to process the CA key rollover. If the certifying certifier's ID file is used for the CA key rollover process, then this happens immediately. But if the CA process is used, then this final sequence does not occur until the ID file of the CA being rolled over is opened at some point in the future to issue a certificate (whenever that is done, the directory on the Registration server is searched for new certificates to be added to the Certifier ID file).

Rollover certificates

About this task

In order to support certifier key rollover, the Domino trust model includes a type of certificate called the rollover certificate. These are certificates issued by an entity to itself. In a hierarchical certificate, there is a single issuer name, a single subject name, and a single subject key. In a rollover certificate, there is a single name (which is both the issuer and the subject) and two subject keys: one key is used to sign the certificate and attests to the fact that the subject name is legitimately in possession of the other key.

Generally, when a key is rolled over, two rollover certificates are issued: one signed by the old key saying that the new key is valid; and the other signed by the new key saying that the old key is valid. Each certificate has its own expiration date.

Rollover certificates are essential for limiting the expiration dates of certificates issued to the older keys. One of the reasons for rolling over a key is that a former key has been compromised, or at least be considered to be old enough that the probability of compromise is considered unacceptable. In such cases, by limiting the expiration date specified in a rollover certificate, it is possible to limit the lifetime of a formerly issued child certificate by specifying an early enough expiration date in the rollover certificate. Administrators should estimate how long the rollover process will take to complete and make sure that the rollover certificates have an expiration date that is further out than the estimate.

Rolling over a certifier

About this task

Rolling over a certifier affects the whole organization. Once you have rolled over a certifier, you must roll over or recertify all user IDs, server IDs, and cross-certificates that were issued by that certifier.

The best way to rollover an entire customer site is to start at the root certificate and descend through the hierarchy. Begin by rolling over the root CA, and then the OU CAs. Then roll over server and user keys. If a user or server key is rolled over before that of the parent CA, then the new user or server key will need to be certified twice -- once with the current (old) CA key, and then again when the CA key rolls over. The extra recertification is expensive, in terms of time and effort -- user and server recertification require administrator intervention, as well as the replication of Person and Server documents.

To roll over a CA certifier, complete the following steps:

Note: These steps describe re-certifying IDs. However, if the IDs are compromised or need larger key sizes, roll over the IDs instead. For information on user and server key rollover, see User and server key rollover.

Procedure

1. Assign a new key pair to the certifier.

2. Re-certify any organizational unit (OU) certifier ID issued by that certifier.

3. Re-certify server IDs that were issued by that certifier.

4. Re-certify user IDs that were issued by the certifier.

5. Roll over cross-certificates that were issued by the certifier.

6. Re-sign items that were signed by entities certified with the previous certifier key.