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:

  • The current key is considered too short for adequate encryption. Longer keys are more secure and less vulnerable to tampering. Ideally, CA keys should be 2048 or 4096 bits in length.
  • The current key is too old. Current® Domino® CA keys are often older than ten years; shorter key lifetimes are generally recommended. You can specify the key lifetime at rollover.
  • The value of the current private key has been compromised.

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 has been extended to include a new type of certificate - 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.

The certifier rollover process

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.

Procedure

  1. First, you must assign a new key pair to the certifier.
  2. Roll-over or re-certify server IDs that were issued by that certifier.
  3. Roll over or re-certify user IDs that were issued by the certifier.
  4. Re-certify cross-certificates that were signed by the certifier.