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 curent 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.

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

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 certifer rollover process

Rolling over a certifier affects the 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 top and work down. 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 befor 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 and effort: user and server recertification require adminstrator intervention, as well as the replication of Person and Server documents.

Note Clients using IBM® Lotus® Notes® releases earlier than 8.0 cannot accept CA rollover certificates. Therefore, if you have a mixed-release client deployment, you cannot proceed with CA key rollover until all users are upgraded to the Lotus Notes 8 client.

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.

Glossary