The Domino Certificate Authority Rollover Process

The Domino Certificate Authority Key Rollover Process
Author: Graham Farrell

IBM Domino server Support Engineer
1
Introduction. ........................................................................................................................................................... 3
Terms and Abbreviations ........................................................................................................................................ 4
The Domino Certificate Authority and The Domino CA Process ............................................................................ 5
Domino Certificate Trust Hierarchy ........................................................................................................................ 5
Cross Certificates, Policies Agents, ECLS & Templates ........................................................................................... 8
Information and Data Required To Troubleshoot Key Rollover PMRs. .................................................................. 9
Key Rollover Without ID Vault .............................................................................................................................. 10
Steps To Be Taken Prior To Starting The Key Rollover ..................................................................................... 10
1 - Make Sure All User Renames Have Completed. ..................................................................................... 10
2 - Log And Correct Public Key Mismatches ................................................................................................. 11
3 - Ensure Replication Is Functioning Correctly. .......................................................................................... 15
4 - Recertify Your Users................................................................................................................................ 15
5 – Determine If You Will Rollover Or Just Recertify Your Servers and Users, ............................................ 18
6 – Backup your environment. ..................................................................................................................... 18
Introducing The GFRT Organisation Test Environment. ....................................................................................... 18
Executing The Key Rollover .............................................................................................................................. 19
1 - Rollover the Organisation Certifier. ....................................................................................................... 19
2 - Rollover the Organisation Unit Certifiers. .............................................................................................. 25
3 - Rollover The Servers. ............................................................................................................................. 30
4 - Rollover Your Users. ............................................................................................................................... 36
Key Rollover With ID Vault ................................................................................................................................... 41
How ID Vault Influences The Key Rollover ....................................................................................................... 42
Steps To Be Taken Prior To Starting The Key Rollover ..................................................................................... 46
1 - Make Sure All User Renames Have Completed. ..................................................................................... 46
2 – Disable Public Key Checking. .................................................................................................................. 46
3 - Log And Correct Public Key Mismatches ................................................................................................. 46
4 - Ensure Replication Is Functioning Correctly. .......................................................................................... 51
5 - Ensure Your Users Local ID and Vaulted ID Have The Same Password. .................................................. 51
6 – Backup your environment. ..................................................................................................................... 52
Introducing The GFVRT Organisation Test Environment. ..................................................................................... 52
Executing The Key Rollover .............................................................................................................................. 53
1 - Rollover the Organisation Certifier. ....................................................................................................... 53
2- Rollover the Organisation Unit Certifiers. ............................................................................................... 59
3 - Rollover The Servers. ............................................................................................................................. 63
4 - Recertify Your Users................................................................................................................................ 67
5 – Recreate The Vault Trust And Password Reset Certificates. .................................................................. 69
6 – Rollover Your Users. ............................................................................................................................... 76
Conclusion ............................................................................................................................................................ 79
2
Introduction.
The Domino Certificate Authority Key Rollover process allows an organisation to assign new private
and public keys to their Domino Certificate Authority and to their Organisational Units, Servers and
Users. The act of providing new private and public keys is known commonly as Key Rollover and will
be referred to as such for the rest of this document.
The intention of this document is to provide supplementary information to the Domino Administration
help documentation for this topic and to allow you as a valued IBM customer prepare for and
successfully complete a certificate key rollover for your organisation. As such the document covers
how to complete a key rollover for organisations who have not implemented ID Vault and for
organisations who have implemented this security feature. Given this the document is written to show
how a key rollover should be executed as it was intended and designed by IBM Domino development.
Any known/reported SPRs that exist at the time of writing have been highlighted in the relevant
sections and links to technotes which provide work arounds are also provided. When planning your
key rollover please confirm if the SPRs have been resolved in your current version of Domino before
beginning your key rollover.
The examples in this document show how to complete a top down rollover where the key strengths
are being increased for the Organisation certifier on down to the users, as this can prove to be the
most troublesome rollover type for some customers. The information can however be also used by
customers who simply wish to roll over their Organisation and Organisational Unit certifiers to a new
set of keys without changing their key strength, or for customers who simply wish to rollover their
users. Once the correct preparation has been completed beforehand, the process of completing a
certificate rollover for an organisation should be a trouble-free experience. While every effort has
been made to ensure the accuracy of the information provided, the document does not and cannot
cover issues that may arise in a customer’s Domino domain due to specific configurations or third
party tools used by an individual customer.
The document is written with the latest version of IBM Domino Server and Notes client, which at the
time of writing is 9.0.1 FP6, installed for demonstrating the steps required for a key rollover.
The information can be used for previous versions of IBM Domino Server and Notes client including
version 8.5.3; however, you should check with IBM Domino Server support if there are any known
issues with your installed version(s) prior to beginning a rollover and that you select the key strengths
supported by your Domino and Notes version.
3
Terms and Abbreviations
During the course of the document the following terms and abbreviations will be used. This section is
intended simply to introduce these items for the reader and a full explanation will be provided in the
relevant section of the document.
Organisation Certifier: The first certifier created when a Domino is first installed and from which all
other certificates are generated.
A.K.A. O Certifier, O Certificate, Root Certifier, Root Certificate Org Certifier, Org Certificate, CERT.ID,
Top Level Certifier, Organisation level certifier, Domino CA, Domino Certificate Authority.
Organisational Unit: Certifiers that can be created in Domino to group servers and users in logical sub
divisions, such as by department or geographical area and mimic the hierarchy of an organisation.
A.K.A.: OU, OUs, OU Certifier, OU Certificate, OU Cert, OU ID.
Key Rollover: The act of assigning new public and private keys to a certifier, often done to increase
the key strength of a certifier. Key Rollover is normally completed in a top down fashion, as will be
shown in this document but an organisation can choose just to roll over their users.
A.K.A.: Domino Certificate Key Rollover process, Domino Key Rollover.
Rollover Certificate: Certificate created during a rollover to provide a link between the old and new
public keys sets for a certificate.
Recertify: The act of renewing a user’s ID often to prevent it from expiring.
Certify: The act of stamping a physical ID file, typically belonging to a OU or server, to prevent the ID
from expiring or in some cases add another language, alternative name etc or in some cases to re-
establish the certificate trust hierarchy.
This action can be executed against a user’s ID file but it is generally recommended to recertify users
and certifying a user ID should only be done when advised by IBM Domino Server support.
Domino Certificate Trust Hierarchy: The certificate level trust from the Organisation certifier down to
an individual user’s certificate. The trust can be seen be examining the ID properties of each file in the
hierarchy and comparing the public key identifiers.
A.K.A: Domino Trust Model, Domino Certificate Chain.
Domino Directory: The official title of the names.nsf database for your organisation.
4
The Domino Certificate Authority and The Domino CA Process
The Domino Certificate Authority should not be confused with the Domino Server Based Certificate
Authority Process. The Domino Server Based Certificate Authority Process which will be referred to as
the Domino CA Process for the duration of this document provides a level of abstraction when
administering the Domino Certificate Authority. If implemented in an organisation, the Domino CA
Process should also be used to execute the key rollover. Further information on the Domino CA
Process can be found in the Administration Help documentation and in the following education on
demand document: http://www-01.ibm.com/support/docview.wss?uid=swg27006424
Domino Certificate Trust Hierarchy
Before discussing how to execute a key rollover, it is important to discuss the certificate trust hierarchy
so that when the keys are changed during the rollover and the rollover certificate is introduced the
changes can be understood.
Domino can be set up to mimic their organisation’s structure or hierarchal name scheme. To facilitate
this Domino uses two certifier IDs Organisation and Organisational Unit. The Domino certificate trust
hierarchy refers to the certificate trust from the top level certifier down to each individual user in an
organisation.
The Domino Certificate Trust Hierarchy starts with the Organisation certifier/Domino Certificate
Authority. This certifier is the top level certifier which is created when an organisation first creates
their Domino domain and is named CERT.ID by default and this certifier also certifies the
Administration server and Administrator’s ID during the domain setup by default.
Organisational Unit Certifiers, are used to represent departments or geographic areas within the
organisation. As an organisation you can have up to four levels of Organisational Unit certifiers.
The first level Organisational Unit certifiers are registered using the Organisation certifier, the second
to fourth level Organisational Unit certifiers are then registered using the first or subsequent level
Organisational Unit certifier. The Organisational Unit certifiers are then used to register servers and
users associated with each Organisational Unit. Note small organisations may decide not to implement
Organisational Units and register all servers and users using the Organisation certifier. Organisations
may register all their servers under their Organisation certifier or decide to register their servers under
different Organisational Units, or even use a dedicated Organisational Unit for registering servers.
5
/Acme
North/ South/
Acme Acme
Servers
Sales/North/Acme HR/North/Acme Dev/South/Acme Sales/South/Acme
Users Users Users Users
This trust hierarchy can be seen within the properties of the ID file for a user, server and Organisational
Unit by comparing the public key identifiers to ensure they match.
Key identifier for the OU
User’s Key Identifier and

certificate validity period
6
Key Identifier for the
Organisation certifier
OU’s Key Identifier and

certificate validity period
Key identifier and validity

period for the Organisation
certifier, which is a self-
signed certificate
7
When reviewing the ID properties for the Organisational Unit and organisation certifier, ensure the
same key identifier for these entities as were present in the user’s ID file. Having the same key
identifiers indicates that the correct trust hierarchy id in place.
Servers do not appear as part of the trust hierarchy in the ID properties of a user’s file. The ID for a
server should also be examined if required to ensure the correct trust hierarchy is in place between it
and the required Organisational Unit and the Organisation certifier.
It should be noted however that there are hidden entities such as the private keys that also play a part
in the trust hierarchy which cannot be viewed through the Administration client. In PMRs where an
issue has been reported with a key rollover, IBM development do have internal tools for checking
these entities and that the correct trust is in place by running these tools against the ID files for the
certifiers.
Cross Certificates, Policies Agents, ECLS & Templates

When you planning a rollover, you need to be aware of how to deal with your policies, agents,
execution control list and if present Cross Certificates are handled.
By default, these items will be signed by a certifier, user or in some cases server ID. When the signing
entities are rolled over Domino does not automatically resign these items with the new key and the
administrator must manually complete this action.
For policies, the policy and related settings document(s) must be resigned once the original signer has
been rolled over. This is a simple process where the document must be brought into edit mode by the
signer and then saved, however some customers have reported that they need to make a small change
to the document and then remove the change for the document to be resigned.
ECLs, agents and any custom templates must also be edited and resigned once the signer has been
rolled over.
With cross certificates, if you have given another organisation access to your domain you should
provide them with a new safe copy of the corresponding certifier or server ID once it has been rolled
over. The organisation should then delete their current cross certificate for your organisation and
create a new cross certificate from the safe copy you provided them with. If the organisations end
users have copies of the cross certificate in their local address book these need to be replaced with
the new cross certificate.
IF you are accessing another organisation, you should request that they send you a new safe copy of
the ID file that you are cross certified by. Once received you should delete the current cross certificate
8
and create a new cross certificate with the corresponding rolled over ID. If any of your users have a
copy of the cross certificate in their local address book the existing copy should be removed and the
new copy pushed down.
As with all other entities you have until the rollover certificates expiry to carry out these actions.
Information and Data Required To Troubleshoot Key Rollover PMRs.

If an issue does arise when completing a key rollover in your organisation, the following information
and data will be required by IBM Domino Server support.
1. The type of rollover that you are completing, and when you began the key rollover.
2. An un-encrypted OS level copy of your Domino Directory.
3. OS level copies of your Organisation certifier, one of the affected Organisational Unit
certifiers, your Administration server and one Mail server ID files and one affected user’s ID
file.
4. An un-encrypted OS level copy of the log.nsf from the Administration server, the mail server
and the Administrator and affected user.
Please note there maybe additional debug required and requested by support. For example, the
engineer may ask that you enable the following parameter on your ID Vault server
DEBUG_IDV_UPDATE=1
This parameter will report ID files that are updated in the vault in relation to the new public keys
being applied during the rollover to the console.log file.
9
Key Rollover Without ID Vault
At the time of writing there are three SPRs that have been reported to development in relation to
performing a key rollover without the ID vault.
SPR # GFALABDNBW, which reports an issue where the user rollover fails due to the user’s local
certificate not being updated correctly. Please see the following document for additional information.
http://www-01.ibm.com/support/docview.wss?uid=swg21986477
SPR # GFAL9SHL6K, which reports access errors for users when their server is rolled over. Please see
the following document for additional information.
SPR # GFALABDNFQ, which reports errors appearing in the Miscellaneous view of the local log.nsf
database for a rolled over user. Testing by support would indicate that these messages are being
logged in error as the users have no access issues. Please see the following document for additional
information.
As stated earlier the steps in this document are based on how the key rollover should be executed as
originally intended and designed by IBM Domino development and as such do not make allowances
for the issues reported in the above SPRs. Please confirm if the above SPRs have been resolved in
your current version of Domino before beginning your key rollover.
Steps To Be Taken Prior To Starting The Key Rollover
The following is a list of items that should be checked and/or undertaken before an organisation
begins a key rollover.
1 - Make Sure All User Renames Have Completed.

During the rollover period you cannot start or complete a user rename. This includes rename actions
such as “Change Common Name” and “Request Move to New Certifier” request. Please ensure that
these operations have completed for all users before beginning the rollover.
10
2 - Log And Correct Public Key Mismatches
If your organisation does not have public key checking enabled, you should enable this setting using
the value “Log key mismatches for all Notes users and Domino servers” within the security tab of your
server document, before starting a key rollover to ensure that the user’s local ID and Person document
contain the same public key information. The server will require a restart to have this setting take
effect.
The option logs the following message to the console.log file and log.nsf database, when a user with
a mismatched public key logs into the server
“User name/org from host [ipaddress:port] encountered non-fatal problem during authentication:
Your public key was not found in the Domino Directory”
You can also set up an event handler to send an email or log to a database every time the error appears
on the server console.
To do so, open the events4.nsf database or the Configuration Tab  Monitoring Configuration 
Event Handlers view and click New Event Handler in the Administration client.
On the Basics tab
Select the servers which you wish to have the event handler active on, or leave the option “Notify of
the event on any server in the domain” selected.
Leave the Trigger as the default “Any event that matches a criteria”.
11
On the Event tab set the following
Events can be any type
Events can be any severity
Events must have this text in the event message, enter the text of the error as follows Your public key
was not found in the Domino Directory
12
On the Action Tab:
Choose your preferred notification method and how the notification is enabled.
Click Save & Close too active the handler.
For a list of each of the notification methods please review the ‘Event Handler Notification Methods’
article in the Administration help documentation.
To correct a reported public key mismatch, you can recertify the users (see the section on completing
this action later in the document) or you can take a copy of the user’s local ID file and complete the
following steps.
1. In the Administration client select Configuration Tab  Tools  Certification  ID

Properties, select the user’s ID file and enter the password for the ID file.
2. Expand the ‘Your Identity’ tab and select ‘Your Certificates’.
3. The user’s name will appear twice in the list. Select either instance of the name and click
Other Actions  Mail, Copy Certificate (Public Key)  Copy Certificate. This will place the
public key from the user’s ID file into the system’s clipboard memory.
13
4. Open Notepad or a similar low level text editor and select its Paste function to copy in the
user’s public key from the clipboard, then open the user’s Person document in the Domino
Directory of your Administration server and select the Certificates Tab and click Edit Person.
5. Compare the value of the Notes Certified Public Key field against the public key copied from
the user’s local ID file. There should a difference between them. Remove the contents of the
Notes Certified Public Key field and paste in the public key from Notepad into this field1
1
If there is no mismatch between the public keys in the user’s local ID and person document this would
indicate possible corruption of their person document. If offline maintenance on the Domino Directory does
not resolve the error, please open a PMR with IBM Domino Server support
14
6. Click Save & Close and allow the change in the person document to replicate to each server
in the domain, then have the user log into their Notes client and confirm the error is no
longer reported for this user.
3 - Ensure Replication Is Functioning Correctly.

This is mainly to ensure that the Domino Directory and Administration Requests database is replicating
correctly between all your servers.
Please review the following document in relation to any question or troubleshooting tips you may
need for replication http://www-01.ibm.com/support/docview.wss?uid=swg21693949
4 - Recertify Your Users.

This action may seem like a redundant step considering that you are planning a rollover, however it
can ensure that your users local IDs are correctly stamped and that there is no issue with the ID file or
their person document in the Domino Directory which may cause access issues for the user once the
rollover has begun. The action should most definitely be taken for user’s whose ID are about to expire.
It should be noted that recertifying your users will update their public keys validity dates but not their
public key or key identifier,
Recertifying your users should be done based on their Organisational Units (if used) by using the
following steps.
1. Open the Administration client, connect to the Administration server and select the People
& Groups Tab.
2. Select the People  By Organisation View. Expand the view for the organisation unit which
you wish to start with.
3. Select each of the user’s belonging to the organisation unit and select People  People 
Recertify.
4. On the ‘Choose a Certifier’ dialog make sure the Administration server and correct
organisation server is selected, if not update these fields as required, click OK and enter the
password of the Organisational Unit certifier.
5. On the ‘Renew Certificates In Selected Entries’ dialog, the expiration date will be for two
years. If you wish to you can change this value and then click OK.
15
6. Each user will be presented in the ‘Recertify User’ dialog. Click OK for each user.
7. On the ‘Processing Statistics’ dialog should report success for all the users, if any errors are
reported review the Certification log.
8. Have the user’s log into their Notes client and their local IDs will be updated with the new
information.
Please note that if you save a user’s ID file to file, for example in a folder on a network drive, when
registering your users, that the user’s IDs stored within this folder will not be updated with the new
public key when you recertify a user.
You should obtain a copy of the user’s updated local ID and replace the ID for the user within the drive
with this ID.
Alternatively, you can certify the user’s physical ID in the drive by following the steps listed below.
1. Open your Administration client and select the Configuration Tab  Tools  Certification 
Certify.
2. On the ‘Choose a Certifier’ dialog, make sure the server is set to the Administration server
and that the Certifier ID (if not using the CA process) for the user’s OU is selected, click OK
and enter the password for the OU ID.
16
3. On the ‘Choose ID to Certify’ dialog navigate to the user’s ID file on the drive, click OK and
enter the password for the user’s ID file.
4. On the ‘Certify’ dialog, you can just click Certify, or you can change a value such as the expiry
date.
5. You will be asked if you wish to certify another ID with the same certifier click No.
Once the user’s person document has been updated and the changes replicated across the servers in
the domain have the user log into their Notes client and their local ID will be updated with their new
public key.
17
5 – Determine If You Will Rollover Or Just Recertify Your Servers and Users,
While the focus of this document is on executing a full top down key rollover, organisation can decide
to rollover their Organisation and Organisational Unit(s) and then just recertify the servers and the
users with the rolled over certifiers. Or they can rollover their Organisation, Organisational Unit(s)
and servers only and just recertify their users with the rolled over certifiers.
This will re-stamp the servers and/or users’ ID files with the new public/private key set of the
Organisation and Organisational Unit which updates the Domino Certificate Trust Hierarchy within the
files.
6 – Backup your environment.

With your Administration server shut down take a file level copy of:
1. Your Domino Directory.
2. The Certification Log Database.
3. The ID files for your Organisation certifier, all Organisational Unit certifiers and Servers.
4. The ID files for your users, especially the Administrator(s) ID file.
The backup of these files should be kept safe until the rollover has been completed.
Introducing The GFRT Organisation Test Environment.
For the purposes of this document a test organisation GFRT has been set up in the IBM lab.
The organisation test environment is quite small consisting of the organisation certifier, two
Organisational Units and several users registered under each Organisational Unit.
The organisation has two IBM Domino servers, one which acts as the Administration server for the
organisation and one which acts as the user’s mail and application server. Both servers are registered
under the root certifier and both are running version 9.0.1 FP6.
The key strength for all entities from the Organisation certifier down to the users is currently 1024 bit,
which is the default strength used within version 9.0.1 code stream and the organisation has not set
up an ID Vault to harvest and manage their users’ ID files.
18
The administrator of the organisation has determined that a full top down rollover should be executed
to increase the organisation and Organisational Unit certifiers key strength to 4096 bits, and that the
servers and users should be rolled over to increase their key strength to 2048 bits.
Executing The Key Rollover

As mentioned earlier please confirm if SPR # GFALABDNBW, which reports an issue where the user
rollover fails due to the user’s local certificate not being updated correctly. Please see http://www-
01.ibm.com/support/docview.wss?uid=swg21986477
1 - Rollover the Organisation Certifier.

This begins the rollover for an organisation and applies a new set of public and private keys to the
Organisation certifier. The process also creates the rollover certificates, which are certificates issued
by a certifier to itself. Typically, 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 which by default is two years in length.
The rollover certificates act as a link to allow entities which have not yet been rolled over and still have
references only to the old public and private keys still access the Domino domain and the data within.
The rollover certificates for each entity will be shown/discussed for each certifier as they are essential
to the process.
To rollover the Organisation Certifier complete the following steps.
1. On your Administration client when connected to the Administration Server, select

Configuration Tab  Tools  Certification  Rollover Certifier Key. You will be presented
with the ‘Generate New Certifier Key’ dialog.
19
2. Click the Directory Server Button and choose your Administration server.
3. The ID file button now becomes visible. Click the button and select the ID file for your
Organisation Certifier, which by default is named Cert.ID from your Domino data directory
and enter its password.
4. The details of the ID file will now be displayed in the ‘Generate New Certifier Key’ dialog. In
the New Key Strength List select the desired key strength for your new public/private key
set.
5. The Certificate Expiration defaults to one hundred years from the present date, you can
change this to a lower value if you so wish.
6. In the ‘The selected certifier ID file must be recertified as follows’ section of the dialog, as
this is the top level certifier it recertifies itself and a message to this affect is displayed.
7. Click the Rollover button and the ‘Certify ID’ dialog will be displayed, simply click the Certify
button.
20
8. The ‘New Certifier Key Successfully Generated’ dialog should be displayed which provides
information on the key rollover and suggests that you, now rollover the cross certificates
issued by the certifier. Click Yes
9. You will then receive the following message
The Certifier document in the Domino Directory will be updated with the new public key and expiry
details for the Organisation Certifier and will need to be replicated around each server in the domain.
21
To view the new public key identifiers for the Organisation Certifier complete the following steps on
your Administration client.
1. Select the Configuration Tab  Tools  Certification  ID Properties.
2. Select the Cert.id file and enter the password for the file.
3. Expand ‘Your Identity’ and select ‘Your certificates’.
4. Select the first certificate entry and click on the Advanced Details button.
5. The new Key Identifier in this case is 15N7J 8W6T1 XXEJM EM4X8 YZ871 B147G and the
strength is 4096 Bits as expected.
6. Click close on the ‘Notes Certificate Advanced Details’ dialog and select the next entry in the
certificate list and click the Advanced Details button.
22
As you can see the there is a second key identifier 1Z6U7 UDPR3 PDZCB TTF8B XWMJS 414FD, with a
key strength of 2048 Bits which is issued by the key identifier of the 4096 Bit certificate of the Certifier.
The reason for the second certifier having a different key identifier and a key strength of 2046 Bits is
that this is an International Key, which was implemented originally due to RSA export restrictions
which are no longer imposed and this key is not actively used any longer, but is maintained for
backward compatibility in Domino.
To view the new public keys and the rollover certificates complete the following steps in your
Administration client:
1. Select the Configuration Tab  Tools  Certification  ID Properties and select your
Organisation Certifier ID (Cert.id) and enter the password for the ID file.
2. On the ‘ID Properties’ dialog, expand the ‘Your Identity’ and select ‘Your Certificates’.
3. Select one of the certificate entries and click Other Actions  Show New Public Key Status.
23
4. On the ‘Key Rollover Information’ dialog, click the Show Rollover Certificates button.
On the ‘Key Rollover Certificates’ dialog you will see the following:
The key identifier of the old public key. Under this you will see that the certificate is
archived, and you will see the Rollover certificate from the new key to the old key and the
expiry date of the rollover certificate.
The key identifier of the new public key. Under this you will see the rollover certificate from
the old key to the new key and the expiry date of the rollover certificate
24
2 - Rollover the Organisation Unit Certifiers.
Once you have rolled over the Organisation Certifier, you should then rollover the Organisational Unit
certifiers using the following steps in the Administration client.
1. Select the Configuration Tab  Tools  Certification  Rollover Certifier Key. You will be
presented with the ‘Generate New Certifier Key’ dialog.
3. The ID file button now becomes visible. Click the button and select the ID file for the first of
your Organisational Unit Certifier that you wish to rollover and enter its password.
set.
6. In the ‘The selected certifier ID file must be recertified as follows’ section of the dialog, the
parent certifier name will be displayed, however you must click the ‘Parent Certifier’ button
and select the physical ID file of the Organisation Certifier and enter its password. If using
the CA Process, select the option button select the certifier from the drop down list click OK.
7. The Rollover button now becomes active click on this button and the ‘Certify ID’ dialog is
then displayed.
8. The Certify ID dialog allows you to set the strength of the password, or change the expiry
date for the certifier, along with adding an additional language if you wish. However, for a
rollover you should just click the Certify button.
25
9. The ‘New Certifier Key Successfully Generated’ dialog is now displayed with the option to
rollover the cross certificates issued by the Organisational Unit certifier, click the Yes button
to complete this action.
26
10. You will then receive an informational message to state that the certifiers keys have been
rolled over to a new set.
The Certifier document for the Organisational Unit in the Domino Directory will be updated with the
new public key and expiry details for the Organisation Certifier and will need to be replicated around
each server in the domain.
If you have any lower level Organisational Unit certifiers who were registered using the rollover
Organisational Unit certifier, you will need to complete the above steps to roll over the lower level
Organisation Unit certifiers, using the rolled over Organisational Unit certifier as the Parent Certifier.
27
To view the new public key identifiers for the Organisation Unit certifier complete the following steps
on your Administration client.
2. Select the ID file for the Organisational Unit certifier and enter the password for the file.
5. The new Key Identifier in this case is 1A3PK 3169V AQB5F 63SDX ZX32Z A3453 and as it is
the International Key has a strength is 2048 Bits as expected and has an Issuer Key Identifier
of 15N7J 8W6T1 XXEJM EM4X8 YZ871 B147G which if the new Key Identifier of the
Organisation Certifier.
6. Select the second certificate entry and click on the Advanced Details button.
7. The new Key Identifier is 1J5MZ 2G4MV K4QK6 PCDDM XKRNR E24A3 and it has the key
strength of 4096 Bits and has an Issuer Key Identifier of 15N7J 8W6T1 XXEJM EM4X8 YZ871
B147G which is the new Key Identifier of the Organisation Certifier.
8. Select the entry for the Organisation Certifier and its Key Identifier and Issuer Key Identifier
match that of found in the Organisation Certifier.
28
9. To view the rollover certificates for the Organisational Unit, select Configuration Tab 
Tools  Certification  ID Properties. Select the ID file for the Organisational Unit and enter
its password.
10. Select one of the entries for the Organisational Unit certifier and click Other Actions  Show
New Public Key Status.
11. On the ‘Key Rollover Information’ dialog, click the ‘Show Rollover Certificates’ button to view
the rollover certificates and their expiry date.
29
3 - Rollover The Servers.
As mentioned earlier please confirm if SPR # GFAL9SHL6K, which reports an issue regarding rolling
over your servers as documented in the link below has been resolved in your current version of
Domino before beginning your key rollover.
As mentioned earlier if you wish to you can choose to rollover your Organisation and Organisational
Unit certifiers and not your organisations severs and users. If you decide to implement this in relation
to your servers, please see the Administration Help topic “Recertifying a server ID” for instructions on
how to complete this task. However, in this document we are rolling over the servers to increase their
key strength to the current maximum value of 2048 Bits.
It should be noted that when rolling over your servers you are not given the option to rollover any
cross certificates created/signed using the server ID rather than your Organisation or an
Organisational Unit certifiers. Given this you must manually recreate these cross certificates.
When rolling over your servers it is recommended to start with your Administration server, to
complete the rollover using your Administration client connect to the server and complete the
following steps.
1. Open the server document, select the Administration tab and click Edit Server.
2. In the ‘Public Key Requirements’ section set the ‘Minimum allowable key strength’,
‘Maximum allowable key strength’ and ‘Preferred key strength’ to your required key
strength, in this case ‘Compatible with Release 7 and later (2048 bits)
3. Set the ‘Don’t automatically generate a new key before’ field to one day earlier than the
current date, for example if rolling over the server on the 20/5/16 enter 19/5/16 into this
field.
30
4. Click Save & Close and the requirements will be written to the server’s ID file.
5. Once a trigger condition has occurred the key rollover will be initiated and new keys will be
written to the server’s ID file marked as pending.
6. Restart the server this will create a ‘Certify new key request’ in the Administration Requests
database.
You can view the requirements and if a trigger has occurred by selecting the Configuration
Tab  Tools  Certification  ID Properties and selecting the ID file for the server.
In the ‘ID Properties’ dialog expand ‘Your Identity’ and select ‘Your Certificates’. Select one
of the certificate entries for the server and click Other Actions  Show New Public Key
Status.
In the ‘Key Rollover Information’ dialog, the ‘Public key requirements’ section show when
the requirements were copied to the ID and what the rollover criteria are. If a trigger has
occurred and the new keys written to the Id and the ‘Certify new key request’ is present in
the Administration Requests database.
31
7. Open the Administration Requests database and select the Certify New Key Request view.
You will see an entry for your administration server.
8. Select your server and click ‘Certify Selected Entries’
32
9. In the ‘Choose a Certifier’ dialog make sure your Administration server is set in the server
field and click the ‘Certifier ID’ button, select the ID file for the Organisation certifier or the
Organisation Unit under which the server is certified by and click OK and enter the password
for the certifier.
(If using the CA Process select the option button and select the certifier which the server is
registered under and just click OK)
10. The ‘Certificate Expiration Date’ dialog will now be displayed with a default date of two years
from the current date, you can increase this date if you so wish. Click the OK button.
11. The ‘Certify New Keys’ dialog is now displayed which shows the new key identifiers for the
server, click the OK button and the Processing Statistics dialog will now be displayed which
should display a success message.
33
12. On the server console, issue the command Tell Adminp Process All to complete the key
certification process and make sure to give enough time to allow the request to be
processed, the server document updated and the change replicated around the other
servers in the domain.
13. Restart the server, which causes the server to read its configuration and accept the new
keys.
Repeat the above steps for all other servers in your organisation. Please note that the Certify New Key
request for the servers must be executed within the Administration Requests database on your
Administration server. The changes to the server document will then have to be update in the Domino
Directory and replicated to the server in question as well as all other servers in the domain.
You can view the new public key identifiers and rollover certificates within the server’s ID files by
following the same steps as explained earlier in the document for examining these entities in the
Organisation and Organisational Unit certifiers. However, unlike the Organisation and Organisational
Unit certifiers, the server ID will also contain rollover certificates for the Organisation and
Organisational Unit certifier which was used to register the server.
34
Rollover your servers without increasing the key strength.
It may be that your servers’ key strength is at the current maximum of 2048 Bits. In this case you
cannot update the key strength fields to act as a criteria and rollover trigger.
To rollover your servers in this case your server’s current key creation date must be over 180 days
prior to the current date if you wish the rollover criteria to be created and set straight away, otherwise
the rollover criteria will be set once the key creation date is over 180 days.
In your Administration client:
1. Select the server document and click the ‘Edit Server’ button.
2. Select the Administration Tab.
3. Set the ‘Maximum allowable age for key’ to its minimum value of 180 days.
4. Set the ‘Don’t automatically generate a new key before’ field to yesterday’s date.
5. Click Save & Close. Once the trigger occurs rollover your server as outlined in the previous
section.
35
4 - Rollover Your Users.
As mentioned earlier in the document if you wish you can simply recertify your users rather than roll
them over. This action will update their local ID with a new validity date and will update the Domino
Certificate Trust Hierarchy within their local ID file with the new key identifiers of their Organisation
Unit and the Organisation certifiers. It will not however increase their public key strength. Please
follow the steps list in the section “Recertify Your Users” earlier in this document for the steps required
to recertify your users.
You can also use the following steps to rollover your users to increase their key strength and not
rollover the Organisation, Organisational Unit certifiers and Servers.
As the ID vault is not implemented your users will be presented with a number of dialogs during the
rollover process. You should make your users aware of these dialogs before you begin the rollover so
that they are familiar with them and know what to do when they appear. It is possible for a user not
to accept the rollover of their public keys.
The result of the users not accepting the rollover of their IDs will be that once the rollover certificates
for the Organisation and Organisational Unit expire they will no longer be able to access any server in
the domain. To correct this an administrator must physically certify the user’s ID and replace this ID in
the user’s local Notes data directory and copy the new public key from the user’s ID into the user’s
person document in the Domino Directory if public key checking is enabled.
Configure The User Rollover Settings In A Security Settings Policy Document.

User key rollover is controlled by a security settings document, which can be applied to the users
through their Organisational Policy or an Explicit policy.
The following settings should be set in the security settings document in the Keys and Certificates tab.
1. Set the ‘Minimum allowable key strength’, ‘Maximum allowable key strength’ and ‘Preferred
key strength’ fields to ‘Compatible with Release 7 and later (2048 Bits)
2. You can leave the ‘Spread new key generation for all users over this many days’ field set to
180 days or set it one of the other values within the predefined list. This setting determines
how long between the policy being applied to the user and the date the new keys will be
generated and rolled over for the users. Click Save & Close and once the update task runs
and the document is replicated across the other servers in the domain it will be available for
your users.
36
3. When your users next log into their Notes client their local policy documents should be
updated with the new policy settings.
The Users Are Prompted To Create New Public Keys

Once the security policy has been applied to the user and a rollover trigger occurs, the next time the
user logs into their Notes client and attempt to access their mail server, they will be asked to create
new public keys through the ‘Create New Public Keys’ dialog.
Your users should not change any of the settings within this document and should just click the ‘Create
Keys’ button and the dialog will close and their mail file on their server will open.
At this point Key Rollover has been initiated and new keys have been created in the user’s ID and
marked as pending.
The Users Are Prompted To Copy Their ID File

Once the key rollover has been initiated and the new keys have been created, the next time the user
logs into their Notes client and attempts to connect to their mail server they will be presented with
the ‘Copy ID File’ dialog.
This dialog informs the user about the new public keys and allows them to make a copy of their ID file
with the new keys, which can be copied to any other system where they have a copy of their ID file
located. This allows the copy of the ID file on these remote systems to be updated when the rollover
is competed and they log to these systems.
If the user does have copies of their ID file have them click the ‘Yes’ button and save the copy.
37
Execute the Certify New Key Request in the Administration Requests database.
At this point a ‘Certify New Key Request’ will be created in the Administration Requests database for
the user on their mail server
Once this request has been replicated to the Administration server, using the Administration client
complete the following steps.
1. Open the Administration Requests Database and select the Certify New Key Requests view.
2. Select the user’s name in the view.
3. Click ‘Certify Selected Entries’ and the ‘Choose a Certifier’ dialog will be displayed.
4. Make sure the Server is set to the Administration server and the Certifier ID is pointing to
the user’s Organisational Unit certifier. If it is not click the ‘Certifier ID’ button, select the
user’s Organisational Unit certifier ID file, click OK and enter its password.
(If using the CA Process, select the option button and select the users Organisation Unit from
the drop down list and click OK)
5. On the ‘Certificate Expiration Date’ dialog the expiry date will default to two years from the
current date, you can change this value if you so wish and click OK
6. The Certify New Keys dialog will now be presented which will display the user’s old and new
key information, click OK.
38
7. The Processing Statistics dialog is now displayed. There should be no errors, click Ok.
8. Once the Administration Requests process runs the user’s person document is updated with
their new key and certificate information, this update will have to be replicated to their mail
server and all other servers in the domain.
When the user next logs into their Notes client their local ID will be update with their new keys, and
the rollover has been completed for this user.
To view the new key identifiers and rollover certificates for the user, you can take a copy of their local
ID files and in the Administration client select Configuration Tab  Tools  Certification  ID
Properties.
Enter the ID for the user’s password and select one of the user’s certificate entries in the ‘ID Properties’
dialog. Select Other Actions  Show New Public Key Status and them the Rollover Certificates Button.
You will see the rollover certificates for the user, their Organisational Unit and the Organisation
Certifier and their expiry dates.
Rollover Your Users Without Increasing Their Key Strength

It may be that your users’ key strength is at the current maximum of 2048 Bits. In this case you cannot
update the key strength fields to act as a criteria and rollover trigger, or you do not wish to increase
the users’ key strength.
In this case to rollover your users, the current key creation date for the user must be over 180 days
prior to the current date, if you wish the rollover criteria to be created and set straight away, otherwise
the rollover criteria will be set once the user’s key creation date is over 180 days.
1. Select the security settings document, click Edit Settings and elect the Keys and Certificates
Tab.
4. Click Save & Close.
5. Select the Policy document and click ‘Edit Policy’ and then ‘Save & Close’ to update the
policy document.
39
6. Allow the change to policy document to replicate around the other server in the domain.
7. Have the user’s log into their Notes client to update their local policy settings.
8. Once the trigger occurs rollover your users as outlined in the previous section.
Rollover Your IBM iNotes Users.

You can only rollover your IBM iNotes users by having them execute the rollover using a Notes client
and then upload their rolled over ID file into their mail file.
An enhancement request SPR # WHAM99QAA6 was opened with IBM Development to allow IBM
iNotes users be rolled over through the iNotes interface. Development have closed this enhancement
request as the ID Vault provides this functionality.
40
Key Rollover With ID Vault
At the time of writing there are three SPRs that have been reported to development in relation to
performing a key rollover with the ID vault implemented.
SPR # BBSZA79D8P, which reports an issue where the user rollover fails due to the user’s local
certificate not being updated correctly. Please see the following document for additional information.
SPR # GFAL9SHL6K, which reports access errors for users when their server is rolled over. Please see
the following document for additional information.
SPR # GFALABDNFQ, which reports errors appearing in the Miscellaneous view of the local log.nsf
database for a rolled over user. Testing by support would indicate that these messages are being
logged in error as the users have no access issues. Please see the following document for additional
information.
As stated earlier the steps in this document are based on how the key rollover should be executed as
originally intended and designed by IBM Domino development and as such the steps do not deviate
from this to account for the issues reported in the above SPRs.
Please confirm if the above SPRs have been resolved in your current version of Domino before
beginning your key rollover or if the steps in the related technotes should be taken.
In contrast at the of writing the latest version of Domino and Notes is 9.0.1 FP6. Domino 9.0.1 FP6 has
also introduced a number of fixes relating to user key rollover when the ID vault is implemented and
in relation to user renames when the ID Vault is implemented.
SPR# AKNXA2SNNT - Fixes rollover keys not merging successfully causing invalid vault trust certificate
errors in the local log.nsf. This fix requires the following parameter to be present in the notes.ini file
of your ID vault server(s) for the duration of the rollover, IDV_RefreshCerts=1
SPR# KLYH9ZDQNC - Fixes user ending up in the wrong ID Vault key rollover state due to a timing issue
in processing the key rollover and the refresh of the database view.
41
SPR# PMGYA4CHDZ - Fixes intermittent Domino Server and Notes Client crash when organization is
doing a key rollover. Crash occurs on both client and server side when users try to connect to their
mail server.
SPR# PACY9CGLQ3 - If the Client ID files has a newer name and the ID vault has the older name, after
a sync, the Client ID file is reverted to use the older name and the user loses access.
It is recommended that you upgrade your version of Domino and Notes to the latest version available.
However, if this is not possible please open a PMR with IBM Domino support to see if a hotfix for the
above SPRs can be provided for your version of Domino.
Please note that depending on your version of Domino it may not be possible to provide a hotfix and
if you wish to continue with a key rollover you will have to upgrade your environment.
Another item to note is that in the following sections, in relation to a user logging into their Notes
client and syncing with the ID Vault, that the user’s ID may not sync straight away and it may be the
next day before this action occurs, if the user’s ID already synced in the last eight hours.
Please see the topic “How an ID vault works” in the Administration help documentation in relation to
the eight-hour sync period.
How ID Vault Influences The Key Rollover

Once an ID Vault has been implemented within an organisation, an administrator needs to be aware
of how this changes the key rollover process.
First the users are no longer aware that the key rollover is in place, and they are no longer required to
accept the new public keys. The users are however required to log in to their Notes clients to have
their new public keys downloaded from the ID vault, which based on the current documentation has
caused some confusion with some customers, who believed that the rollover can be completed
without their users logging into their Notes client.
Secondly is the importance the vault trust certificate plays in the key rollover.
When an administrator begins the key rollover of the Organisation and Organisational Unit certifiers
there are no rollover certificates created for the vault trust certificates and password reset certificates,
which results in the following:
1. Users cannot be registered to your organisation and have their ID uploaded to the vault.
When an administrator registers a user to an Organisation or Organisational Unit certifier
that has been rolled over, the follow error is displayed.
42
And in the security events view of the Administrator’s local log.nsf database the following
errors are logged.
ID 'C:\IDs\People\wmcbride.id' failed to upload to vault 'O=OrgVault' on server

'CN=dubxpcvm3994/O=GFVRT'. 'Wille McBride/North/GFVRT' made request. Error: Invalid
Vault Trust certificate chain. Check the log file for details.
ID 'C:\IDs\People\wmcbride.id' failed to upload to vault '' on server

'CN=dubxpcvm3994/O=GFVRT'. 'Dom Admin/GFVRT' made request. Error: Invalid Vault
Trust certificate chain. Check the log file for detail
When you click on the Done button, you are asked if you wish to save the person to the
registration queue, click No as the user will actually be registered to the Domino Directory
and their mail file is created. In this case the user’s ID should also be saved to the Domino
Directory or to a network drive in order to be able to set up the Notes client for the user.
2. An administrator and those users designated with the Password Reset Authority role can no
longer reset user passwords through the ID Vault, or through a Password Reset Application.
On attempting to reset a user’s password the following error will be reported.
43
This is because the user’s local ID still has the vault trust in place, and this needs to be kept in order
for the user’s local ID to be updated with the rolled over information from their vaulted ID.
Once all the users have been rolled over the vault trust and password reset certificates can be
recreated. Then any users registered during the rollover will have their ID automatically uploaded to
the ID vault the next time they log into their Notes client. The administrator and any users granted the
Password Reset Authority role will again be able to reset for users in the ID vault.
As the key rollover process, can take quite some time to complete depending on the number of servers
and users in an organisation, if this design is not acceptable to an administrator and they cannot wait
that long to be able to be able to change user passwords, they must alter the key rollover process
slightly in that they must:
1. Rollover the Organisation and Organisational Unit certifiers.
2. Rollover the Servers.
3. Recertify their users with their rolled over certifiers.
44
4. Recreate the Vault Trust and Password Reset Certificates.
5. Rollover the users.
If an administrator believes that they can wait until all of their users have been rolled over in order to
reset passwords, the rollover steps would be as follows:
1. Rollover the Organisation and Organisational Unit certifiers.
2. Rollover the Servers.
3. Rollover the users.
4. Recreate the Vault Trust and Password Reset Certificates.
As most administrators cannot wait until all their users have been rolled over in order be able to reset
passwords for their users, this document is based on the amended steps where the users are
recertified before they are rolled over.
Please note you cannot implement ID Vault during a rollover this is unsupported and will adversely
affect your key rollover to the level that IBM Domino Server support will be unable to assist you and
consultancy services will have to be purchased by your organisation to resolve your issue.
45
Steps To Be Taken Prior To Starting The Key Rollover
Regardless of whether an administrator decides to amend the rollover steps or not, the following is a
list of items that should be checked and/or undertaken before an organisation begins a key rollover.
1 - Make Sure All User Renames Have Completed.

During the rollover period you cannot start or complete a user rename. This includes rename actions
such as “Change Common Name” and “Request Move to New Certifier” request. Please ensure that
these operations have completed for all users before beginning the rollover.
2 – Disable Public Key Checking.

This option is not enabled by default in a server document, however if enabled it should be disabled
while rolling over your users.
The reason for this is that when a user is rolled over their person document is updated with their new
public key first, and the user must log into their Notes client and authenticate with their mail server
in order for their update their vaulted ID with the new public key and download the update to their
local ID file. However, when Public Key Checking is enabled, as there is a mismatch between the public
key in the user’s person document and their local ID file the user will not be able to authenticate with
their server and the updated ID from the vault will not be updated and downloaded to the user’s local
ID file and the rollover will not complete unless the user selects File  Security  User Security  ID
Vault Sync to try and force a sync between their local ID and the vaulted ID.
3 - Log And Correct Public Key Mismatches

If your organisation does not have public key checking enabled, you should enable this setting using
the value “Log key mismatches for all Notes users and Domino servers” within the security tab of your
server document, before starting a key rollover to ensure that the user’s local ID and Person document
contain the same public key information. The server will require a restart to have this setting take
effect.
The option logs the following message to the console.log file and log.nsf database, when a user with
a mismatched public key logs into the server
“User name/org from host [ipaddress:port] encountered non-fatal problem during authentication:
Your public key was not found in the Domino Directory”
You can also set up an event handler to send an email or log to a database every time the error appears
on the server console.
46
To do so, open the events4.nsf database or the Configuration Tab  Monitoring Configuration 
Event Handlers view and click New Event Handler in the Administration client.
On the Basics tab
Select the servers which you wish to have the event handler active on, or leave the option “Notify of
the event on any server in the domain” selected.
Leave the Trigger as the default “Any event that matches a criteria”.
On the Event tab set the following
Events can be any type
Events can be any severity
Events must have this text in the event message, enter the text of the error as follows Your public key
was not found in the Domino Directory
47
On the Action Tab:
Choose your preferred notification method and how the notification is enabled.
Click Save & Close to active the handler.
For a list of each of the notification methods please review the ‘Event Handler Notification Methods’
article in the Administration help documentation.
48
To correct a reported public key mismatch, you can recertify the users (see the section on completing
this action later in the document) or you can take a copy of the user’s local ID file and complete the
following steps.
1. In the Administration client select Configuration Tab  Tools  Certification  ID

Properties, select the user’s ID file and enter the password for the ID file.
2. Expand the ‘Your Identity’ tab and select ‘Your Certificates’.
3. The user’s name will appear twice in the list. Select either instance of the name and click
Other Actions  Mail, Copy Certificate (Public Key)  Copy Certificate. This will place the
public key from the user’s ID file into the system’s clipboard memory.
49
4. Open Notepad or a similar low level text editor and select its Paste function to copy in the
user’s public key from the system clipboard, then open the user’s Person document in the
Domino Directory of your Administration server and select the Certificates Tab and click Edit
Person.
5. Compare the value of the Notes Certified Public Key field against the public key copied from
the user’s local ID file. There should a difference between them. Remove the contents of the
Notes Certified Public Key field and paste in the public key from Notepad into this field2
6. Click Save & Close and allow the change in the person document to replicate to each server
in the domain, then have the user log into their Notes client and confirm the error is no
longer reported for this user.
2
If there is no mismatch between the public keys in the user’s local ID and person document this would
indicate possible corruption of their person document. If offline maintenance on the Domino Directory does
not resolve the error, please open a PMR with IBM Domino Server support
50
4 - Ensure Replication Is Functioning Correctly.
This is mainly to ensure that the Domino Directory and Administration Requests database is replicating
correctly between all your servers.
Please review the following document in relation to any question or troubleshooting tips you may
need for replication http://www-01.ibm.com/support/docview.wss?uid=swg21693949
5 - Ensure Your Users Local ID and Vaulted ID Have The Same Password.
If your organisation is not using Password Checking in either the server document or the security
settings document, it is possible for your user’s local ID and vaulted ID to become out of sync and your
users can still access the servers in your domain.
However, if your users local and vaulted IDs are out of sync any changes will not be downloaded from
the vaulted ID to the users local ID. This will mean that the rollover will not complete for the user as
their local ID will not be updated with their new public/private key set.
The Domino Domain Monitor (DDM) records when a user’s ID is not downloaded due to an incorrect
password, or what the vaulted ID believes to be an incorrect password as follows
25/06/2016 11:52:11 PM ID for 'Kate Farrell/North/GFVRT' (IP Address 9.22.122.209:1295) in vault

'O=OegVault' was not downloaded because the wrong password was supplied. Error: Wrong
Password. (Passwords are case sensitive - be sure to use correct upper and lower case.)
While it may be that the user has genuinely typed the wrong password, administrators should review
the entries in the DDM for the same users appearing with this error message over a period of a week
or so. This will give a good indication that the user’s local ID is out of sync with their vaulted ID.
An administrator can also set up an event to report when the message occurs and have this logged to
a separate database if they wish so that they do not have to filter out the messages in the DDM.
To correct this the Administrator should inform the user, change their password in the vault and have
the user download the vaulted copy by entering the new password.
51
6 – Backup your environment.
With your Administration server shut down take a file level copy of:
1. Your Domino Directory.
2. The Certification Log Database.
3. The ID Vault database.
4. The ID files for your Organisation certifier, all Organisational Unit certifiers and Servers.
5. The ID files for your users if kept on a network share as well as the vault, especially the
Administrator(s) ID file.
The backup of these files should be kept safe until the rollover has been completed.
Introducing The GFVRT Organisation Test Environment.
For the purposes of this document a test organisation GFVRT has been set up in the IBM lab.
The organisation test environment is quite small consisting of the organisation certifier, two
Organisational Units and several users registered under each Organisational Unit.
The organisation has two IBM Domino servers, one which acts as the Administration server for the
organisation and one which acts as the user’s mail and application server. Both servers are registered
under the root certifier and both are running version 9.0.1 FP6. The Administration server is also the
ID Vault server for the organisation, and both Organisational Units trust the ID Vault for managing IDs
for the users, while only the administrator has been granted the password reset authority role. The
server also has IDV_RefreshCerts=1 set in the notes.ini for the duration of the user rollover.
The key strength for all entities from the Organisation certifier down to the users is currently 1024 bit,
which is the default strength used within version 9.0.1 code stream.
The administrator of the organisation has determined that a full top down rollover should be executed
to increase the organisation and Organisational Unit certifiers key strength to 4096 bits, and that the
servers and users should be rolled over to increase their key strength to 2048 bits.
The administrator has also decided to recertify their users before rolling over the users, so that the
Vault Trust and Password Reset certificates can be recreated early.
52
Executing The Key Rollover
1 - Rollover the Organisation Certifier.

This begins the rollover for an organisation and applies a new set of public and private keys to the
Organisation certifier.
The process also creates the rollover certificates, which are certificates issued by a certifier to itself.
Typically, 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 which by default is two years in length. The rollover
certificates act as a link to allow entities which have not yet been rolled over and still have references
only to the old public and private keys still access the Domino domain and the data within. The rollover
certificates for each entity will be shown/discussed for each certifier as they are essential to the
process.
To rollover the Organisation Certifier complete the following steps.
1. On your Administration client when connected to the Administration Server, select

Configuration Tab  Tools  Certification  Rollover Certifier Key. You will be presented
with the ‘Generate New Certifier Key’ dialog.
53
3. The ID file button now becomes visible. Click the button and select the ID file for your
Organisation Certifier, which by default is named Cert.ID from your Domino data directory
and enter its password.
the New Key Strength List select the desired key strength for your new public/private keyset.
6. In the ‘The selected certifier ID file must be recertified as follows’ section of the dialog, as
this is the top level certifier it recertifies itself and a message to this affect is displayed.
7. Click the Rollover button and the ‘Certify ID’ dialog will be displayed, simply click the Certify
button.
8. The ‘New Certifier Key Successfully Generated’ dialog should be displayed which provides
information on the key rollover and suggests that you now rollover the cross certificates
issued by the certifier. Click Yes
54
9. You will then receive the following message
The Certifier document in the Domino Directory will be updated with the new public key and expiry
details for the Organisation Certifier and will need to be replicated around each server in the domain.
To view the new public key identifiers for the Organisation Certifier complete the following steps on
your Administration client.
2. Select the Cert.id file and enter the password for the file.
55
5. The new Key Identifier in this case is 18XWD HRP2Q 76XNU NJ4JB KNCA1 U74DF and the
strength is 2048 Bits which is issued by the key identifier of the 4096 Bit certificate of the
Certifier which is identified by the Issuer key identifier 19G1B 5NN2Y K5BGN DGV4P 11F4W
A24BD. The reason for the first certifier having a different key identifier and a key strength
of 2046 Bits is that this is an International Key, which was implemented originally due to RSA
export restrictions which are no longer imposed and this key is not actively used any longer,
but is maintained for backward compatibility in Domino.
6. Click close on the ‘Notes Certificate Advanced Details’ dialog and select the next entry in the
certificate list and click the Advanced Details button.
56
7. As you can see the Key Identifier and Issuer Key identifier of 19G1B 5NN2Y K5BGN DGV4P
11F4W A24BD, with a key strength of 4096.
To view the new public keys and the rollover certificates complete the following steps in your
Administration client:
1. Select the Configuration Tab  Tools  Certification  ID Properties and select your
Organisation Certifier ID (Cert.id) and enter the password for the ID file.
2. On the ‘ID Properties’ dialog, expand the ‘Your Identity’ and select ‘Your Certificates’.
3. Select one of the certificate entries and click Other Actions  Show New Public Key Status.
57
4. On the ‘Key Rollover Information’ dialog, click the Show Rollover Certificates button.
On the ‘Key Rollover Certificates’ dialog you will see the following:
The key identifier of the old public key. Under this you will see that the certificate is
archived, and you will see the Rollover certificate from the new key to the old key and the
expiry date of the rollover certificate.
The key identifier of the new public key. Under this you will see the rollover certificate from
the old key to the new key and the expiry date of the rollover certificate
58
2- Rollover the Organisation Unit Certifiers.
Once you have rolled over the Organisation Certifier, you should then rollover the Organisational Unit
certifiers using the following steps in the Administration client.
1. Select the Configuration Tab  Tools  Certification  Rollover Certifier Key. You will be
presented with the ‘Generate New Certifier Key’ dialog.
3. The ID file button now becomes visible. Click the button and select the ID file for the first of
your Organisational Unit Certifier that you wish to rollover and enter its password.
set.
6. In the ‘The selected certifier ID file must be recertified as follows’ section of the dialog, the
parent certifier name will be displayed, however you must click the ‘Parent Certifier’ button
and select the physical ID file of the Organisation Certifier and enter its password. (If using
the CA Process, select the option button select the certifier from the drop down list click
OK.)
7. The Rollover button now becomes active click on this button and the ‘Certify ID’ dialog is
then displayed.
59
8. The Certify ID dialog allows you to set the strength of the password, or change the expiry
date for the certifier, along with adding an additional language if you wish however for a
rollover you should just click the Certify button.
9. The ‘New Certifier Key Successfully Generated’ dialog is now displayed with the option to
rollover the cross certificates issued by the Organisational Unit certifier, click the Yes button
to complete this action.
60
10. You will then receive an informational message to state that the certifiers keys have been
rolled over to a new set.
The Certifier document for the Organisational Unit in the Domino Directory will be updated with the
new public key and expiry details for the Organisation Certifier and will need to be replicated around
each server in the domain. If you have any lower level Organisational Unit certifiers who were
registered using the rollover Organisational Unit certifier, you will need to complete the above steps
to roll over the lower level Organisation Unit certifiers, using the rolled over Organisational Unit
certifier as the Parent Certifier.
To view the new public key identifiers for the Organisation Unit certifier complete the following steps
on your Administration client.
2. Select the ID file for the Organisational Unit certifier and enter the password for the file.
5. The new Key Identifier in this case is 1CMBK NBYVH AYK2T XFHRR RDUXR 414G8 and as it is
the International Key has a strength is 2048 Bits as expected and has an Issuer Key Identifier
of 19G1B 5NN2Y K5BGN DGV4P 11F4W A24BD which if the new Key Identifier of the
Organisation Certifier.
6. Select the second certificate entry and click on the Advanced Details button.
61
7. The new Key Identifier is 1V2JG SNTX1 4QKR5 RPRQV SZTNE G3491 and it has the key
strength of 4096 Bits and has an Issuer Key Identifier of 19G1B 5NN2Y K5BGN DGV4P 11F4W
A24BD which is the new Key Identifier of the Organisation Certifier.
8. Select the entry for the Organisation Certifier and its Key Identifier and Issuer Key Identifier
match that of found in the Organisation Certifier.
9. To view the rollover certificates for the Organisational Unit, select Configuration Tab 
Tools  Certification  ID Properties. Select the ID file for the Organisational Unit and enter
its password.
10. Select one of the entries for the Organisational Unit certifier and click Other Actions  Show
New Public Key Status.
11. On the ‘Key Rollover Information’ dialog, click the ‘Show Rollover Certificates’ button to view
the rollover certificates and their expiry date.
62
3 - Rollover The Servers.
As mentioned earlier please confirm if SPR # GFAL9SHL6K, which reports an issue regarding rolling
over your servers as documented in
Please confirm if the above SPR have been resolved in your current version of Domino before
beginning your key rollover.
As mentioned earlier if you wish to you can choose to rollover your Organisation and Organisational
Unit certifiers and not your organisations severs and users. If you decide to implement this in relation
to your servers, please see the Administration Help topic “Recertifying a server ID” for instructions on
how to complete this task. However, in this document we are rolling over the servers to increase their
key strength to the current maximum value of 2048 Bits.
It should be noted that when rolling over your servers you are not given the option to rollover any
cross certificates created using the server ID rather than your Organisation or an Organisational Unit
certifier. Given this you must manually recreate these cross certificates.
When rolling over your servers it is recommended to start with your Administration server, to
complete the rollover using your Administration client connect to the server and complete the
following steps.
63
1. Open the server document, select the Administration tab and click Edit Server.
2. In the ‘Public Key Requirements’ section set the ‘Minimum allowable key strength’,
‘Maximum allowable key strength’ and ‘Preferred key strength’ to your required key
strength, in this case ‘Compatible with Release 7 and later (2048 bits)
3. Set the ‘Don’t automatically generate a new key before’ field to one day earlier than the
current date, for example if rolling over the server on the 20/5/16 enter 19/5/16 into this
field.
4. Click Save & Close and the requirements will be written to the server’s ID file.
5. Once a trigger condition has occurred the key rollover will be initiated and new keys will be
written to the server’s ID file marked as pending.
6. Restart the server this will create a ‘Certify new key request’ in the Administration Requests
database.
You can view the requirements and if a trigger has occurred by selecting the Configuration
Tab  Tools  Certification  ID Properties and selecting the ID file for the server.
64
In the ‘ID Properties’ dialog expand ‘Your Identity’ and select ‘Your Certificates’. Select one
of the certificate entries for the server and click Other Actions  Show New Public Key
Status.
In the ‘Key Rollover Information’ dialog, the ‘Public key requirements’ section show when
the requirements were copied to the ID and what the rollover criteria are. If a trigger has
occurred and the new keys written to the Id and the ‘Certify new key request’ is present in
the Administration Requests database.
7. Open the Administration Requests database and select the Certify New Key Request view.
You will see an entry for your administration server.
8. Select your server and click ‘Certify Selected Entries’
9. In the ‘Choose a Certifier’ dialog make sure your Administration server is set in the server
field and click the ‘Certifier ID’ button, select the ID file for the Organisation certifier or the
Organisation Unit under which the server is certified by and click OK and enter the password
for the certifier.
(If using the CA Process select the option button and select the certifier which the server is
registered under and just click OK)
65
10. The ‘Certificate Expiration Date’ dialog will now be displayed with a default date of two
years from the current date, you can increase this date if you so wish. Click the OK button.
11. The ‘Certify New Keys’ dialog is now displayed which shows the new key identifiers for the
server, click the OK button and the Processing Statistics dialog will now be displayed which
should display a success message.
12. On the server console, issue the command Tell Adminp Process All to complete the key
certification process and make sure to give enough time to allow the request to be
processed, the server document updated and the change replicated around the other
servers in the domain.
13. Restart the server, which causes the server to read its configuration and accept the new
keys.
Repeat the above steps for all other servers in your organisation. Please note that the Certify New Key
request for the servers must be executed within the Administration Requests database on your
Administration server. The changes to the server document will then have to be update in the Domino
Directory and replicated to the server in question as well as all other servers in the domain.
You can view the new public key identifiers and rollover certificates within the server’s ID files by
following the same steps as explained earlier in the document for examining these entities in the
Organisation and Organisational Unit certifiers. However, unlike the Organisation and Organisational
Unit certifiers, the server ID will also contain rollover certificates for the Organisation and
Organisational Unit certifier which was used to register the server.
66
Rollover your servers without increasing the key strength.
It may be that your servers key strength is at the current maximum of 2048 Bits. In this case you cannot
update the key strength fields to act as a criteria and rollover trigger.
To rollover your servers in this case your server’s current key creation date must be over 180 days
prior to the current date if you wish the rollover criteria to be created and set straight away, otherwise
the rollover criteria will be set once the key creation date is over 180 days.
1. Select the server document and click the ‘Edit Server’ button.
2. Select the Administration Tab.
7. Once the trigger occurs rollover your server as outlined in the previous section.
4 - Recertify Your Users.

As discussed earlier we are taking this action so that the Vault Trust and Password Reset certificates
can be recreated before the users are rolled over, so that an administrator can change passwords for
existing users in the ID Vault and register new users and have their ID automatically upload to the ID
Vault.
If you decided to just rollover your Organisation and Organisational Unit certifiers and not your users,
you would also complete this action to stamp their IDs with the updated public key identifiers for their
Organisational Unit and Organisation certifiers to correct the Domino Certificate Trust Hierarchy in
the user’s vaulted and local ID file.
It should be noted that recertifying your users will update their public keys validity dates but not their
public key or key identifier,
Recertifying your users should be done based on their Organisational Units (if used) by using the
following steps.
67
1. Open the Administration client, connect to the Administration server and select the People
& Groups Tab.
2. Select the People  By Organisation View. Expand the view for the organisation unit which
you wish to start with.
3. Select each of the user’s belonging to the organisation unit and select People  People 
Recertify.
4. On the ‘Choose a Certifier’ dialog make sure the Administration server and correct
organisation server is selected, if not update these fields as required, click OK and enter the
password of the Organisational Unit certifier.
5. On the ‘Renew Certificates In Selected Entries’ dialog, the expiration date will be for two
years. If you wish to you can change this value and then click OK.
6. Each user will be presented in the ‘Recertify User’ dialog. Click OK for each user.
7. On the ‘Processing Statistics’ dialog should report success for all the users, if any errors are
reported review the Certification log.
8. Have the user’s log into their Notes client and their local IDs will be updated with the new
information from their vaulted ID.
Please note that if you also save the users’ ID file to file, for example in a folder on a network drive,
when registering your users, that the ID file stored within this folder will not be updated with the new
public key when you recertify a user.
You should extract a copy of the user’s updated ID from the vault and replace the ID for the user within
the drive with this ID.
Please note that until the Vault Trust and Password Reset Certificates are recreated the following
errors may appear in the user’s local log.nsf database.
Could not locate certificate for '/South/GFVRT': The signature on the certificate was found to be
invalid. Check the log file for details.
68
ID 'C:\Users\Mike\AppData\Local\IBM\Notes\Data\user.id' failed to synchronize with vault
'O=OrgVault' on server 'CN=dubxpcvm3994/O=GFVRT'. 'Mike Kelly/South/GFVRT' made request.
Error: Invalid Vault Trust certificate chain. Check the log file for details
These errors will be removed once the Vault Trust and Password Reset certificates are recreated and
the user’s local ID is updated from their vaulted ID file.
5 – Recreate The Vault Trust And Password Reset Certificates.

As discussed earlier we are carrying out this step early to allow the administrator register new users
and have their ID automatically upload to the ID Vault and to allow them change passwords for existing
users in the ID Vault. If the administrator had determined that they could wait until all users had been
rolled over to complete these actions, the Vault Trust and Password Reset Certificates would be
recreated after the users have been rolled over.
To recreate these certificates, complete the following steps in your Administration client when
connected to the primary ID Vault server for your domain.
1. Select the Configuration Tab  Security  ID Vault view.
2. Select your ID vault.
3. Select Tools  ID Vaults  Manage.
4. On the ‘Manage Notes ID Vault’ dialog, click Next.
5. In the ‘Vault management tasks’ pane, click ‘Add or remove organizations that trust the
vault’ and ‘Add or remote password reset authorities’ and click Next.
69
6. On the ‘Organizations’ pane Click the Add or Remove button.
7. In the ‘Organizations that trust the vault’ pane, select one of the Organisational Unites and
click the Remove All button, then click the OK and Next button.
70
8. In the ‘Specify names that are authorized to reset passwords’ select the name of the
password reset authority user(s) under one of the Organisational Unit certifiers in the
‘Password reset authority by organization’ pane and click the Remove From All button, then
click Next.
71
9. On the ‘Vault Configuration to be Changed’ pane click the Configure button.
10. If the actions were completed successfully you will be presented with the success pane and
simply click the Done button. If any errors are displayed, please correct these and repeat the
above actions as necessary.
72
11. On the server console issue the following command to update the Certifiers view
load updall -R names.nsf -t ($Certifiers)
12. Allow the change to replicate around each server in the domain.
Now that the Vault Trust and Password Reset certificates have been removed, you must read these
entities using the following steps in the Administration client when connected to the primary ID vault
server.
1. Select the Configuration Tab  Security  ID Vault view.
2. Select your ID vault.
3. Select Tools  ID Vaults  Manage.
4. On the ‘Manage Notes ID Vault’ dialog, click Next.
5. In the ‘Vault management tasks’ pane, click ‘Add or remove organizations that trust the
vault’ and ‘Add or remote password reset authorities’ and click Next.
73
6. On the ‘Organizations’ pane Click the Add or Remove button.
7. In the ‘Trusted Vault Organizations’ dialog, click the Organisational Unit(s) you wish to add as
trusting the vault and click the Add button until each required Organisational Unit has been
added and then click the OK button, then click the Next button.
8. On the ‘Specify names that are authorized to reset passwords’ pane select the name of the
user(s) who will be allowed to reset passwords and use the Add or Add To All button to add
the user(s) to the Organisational Unit(s) which they can reset passwords for, then click Next
74
9. You will now be presented with the ‘Vault Configuration to be Changed’ pane, click the
Configure button.
10. You will now be asked to individually select the certifier for each Organisational Unit whom
you have set as trusting the ID Vault and added a password reset authority against.
75
11. Click the Browse button to select the correct certifier ID file and click the OK button and
enter the password for the ID file. Repeat this process until all the required Organisation
Unit certifiers have been selected.
12. You should now be presented with a success message, click the Done button. If any errors
are displayed, please correct these and repeat the above actions as necessary.
13. Issue the following command on the server console.

load updall -R names.nsf -t ($Certifiers)
14. Allow the changes to be replicated to each server in the domain.
6 – Rollover Your Users.

As mentioned earlier, the rollover is invisible to your users in that they are not required to create new
keys or copy their ID file as they would be if the ID Vault was not in place. It may be advisable to inform
your user’s that a key rollover is in place so that they are quick to inform you of any unusual behaviour
that they come across, so that you can confirm if it is related to the key rollover or not. As mentioned
earlier if you simply wished to rollover your users and not your Organisation and Organisational Unit
certifiers, you can follow the steps in the following sections to complete this task.
Configure The User Rollover Settings In A Security Settings Policy Document.

User key rollover is controlled by a security settings document, which can be applied to the users
through their Organisational Policy or an Explicit policy. It is recommended that the user’s existing
security settings document and policy which enables their membership of the ID vault be edited to
include the rollover criteria. The following settings should be set in the security settings document on
the Keys and Certificates tab.
1. Set the ‘Minimum allowable key strength’, ‘Maximum allowable key strength’ and ‘Preferred
key strength’ fields to ‘Compatible with Release 7 and later (2048 Bits)
2. You can leave the ‘Spread new key generation for all users over this many days’ field set to
180 days or set it one of the other values within the predefined list. This setting determines
how long between the policy being applied to the user and the date the new keys will be
generated and rolled over for the users. Click Save & Close and once the update task runs
and the document is replicated across the other servers in the domain it will be available for
your users.
76
3. When your users next log into their Notes client their local policy documents should be
updated with the new policy settings.
Execute the Certify New Key Request in the Administration Requests database.
When a rollover trigger event occurs, the next time the user logs into their Notes client a ‘Certify New
Key Request’ will be created in the Administration Requests database for the user on their mail server
Once this request has been replicated to the Administration server, using the Administration client
complete the following steps.
1. Open the Administration Requests Database and select the Certify New Key Requests view.
2. Select the user’s name in the view.
3. Click ‘Certify Selected Entries’ and the ‘Choose a Certifier’ dialog will be displayed.
4. Make sure the Server is set to the Administration server and the Certifier ID is pointing to
the user’s Organisational Unit certifier. If it is not click the ‘Certifier ID’ button, select the
user’s Organisational Unit certifier ID file, click OK and enter its password.
(If using the CA Process, select the option button and select the users Organisation Unit from
the drop down list and click OK)
5. On the ‘Certificate Expiration Date’ dialog the expiry date will default to two years from the
current date, you can change this value if you so wish and click OK.
6. The Certify New Keys dialog will now be presented which will display the user’s old and new
key information, click OK.
7. The Processing Statistics dialog is now displayed there should be no errors, click Ok.
8. Once the Administration Requests process runs the user’s person document is updated with
their new key and certificate information, this update will have to be replicated to their mail
server and all other servers in the domain.
9. When the user next logs into their Notes client their local ID will be update with their new
keys from their vaulted ID, and the rollover has been completed for this user.
77
To view the new key identifiers and rollover certificates for the user, you can take a copy of their local
ID files and in the Administration client select Configuration Tab  Tools  Certification  ID
Properties.
Enter the ID for the user’s password and select one of the user’s certificate entries in the ‘ID Properties’
dialog. Select Other Actions  Show New Public Key Status and then the Rollover Certificates Button.
You will see the rollover certificates for the user, their Organisational Unit and the Organisation
Certifier and their expiry dates.
Rollover Your Users Without Increasing Their Key Strength

It may be that your users’ key strength is at the current maximum of 2048 Bits. In this case you cannot
update the key strength fields to act as a criteria and rollover trigger, or you do not wish to increase
the users’ key strength.
In this case to rollover your users, the current key creation date for the user must be over 180 days
prior to the current date, if you wish the rollover criteria to be created and set straight away, otherwise
the rollover criteria will be set once the user’s key creation date is over 180 days.
1. Select the security settings document, click Edit Settings and elect the Keys and Certificates
Tab.
5. Select the Policy document and click ‘Edit Policy’ and then ‘Save & Close’ to update the
policy document.
6. Allow the change to policy document to replicate around the other servers in the domain.
7. Have the user’s log into their Notes client to update their local policy settings.
8. Once the trigger occurs rollover your users as outlined in the previous section.
78
Rollover Your iNotes Users.
In order to rollover your IBM iNotes users who do not have access to a Notes client the following
requirements must be in place.
1. Your iNotes users must already have their ID stored in the ID Vault and within their Mail file,
and these IDs must be in sync. Please review the “Using ID vault with Lotus iNotes” topic in
the Administration help documentation.
2. All connections to your users iNotes servers must be using HTTPS. If you currently do not
have secure connections for your Domino Servers, please review the following
documentation. http://www-01.ibm.com/support/docview.wss?uid=swg21418982
Once these requirements are in place you must apply same steps to your IBM iNotes users, as you do
to your Notes client users.
1. You apply the rollover criteria to your IBM iNotes users through the security settings
document of their policy.
2. You complete the ‘Certify New Key Request’ for the user in the Administration Requests
database.
3. Your users’ ID files within their mail files are updated with their new public/private key set.
For each of the above steps your IBM iNotes users must read or send a signed and encrypted mail, as
this action opens a connection to the user’s ID vault database to confirm that their ID in their mail file
is up to date, and if not initiates a download of the user’s ID from the vault to update their ID within
their mail file.
Conclusion
Thank you for taking the time to read this document. I hope that it has been an informative and helpful
experience that will equip you with the knowledge required to execute the Domino certificate
authority key rollover for your organisation.
79

The Domino Certificate Authority Rollover Process

Uploaded by

Copyright:

Available Formats

You might also like

The Domino Certificate Authority Rollover Process

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

The Domino Certificate Authority Rollover Process

Uploaded by

Copyright:

Available Formats

The Domino Certificate Authority Key Rollover Process

Author: Graham Farrell

A.K.A.: OU, OUs, OU Certifier, OU Certificate, OU Cert, OU ID.

A.K.A.: Domino Certificate Key Rollover process, Domino Key Rollover.

Recertify: The act of renewing a user’s ID often to prevent it from expiring.

A.K.A: Domino Trust Model, Domino Certificate Chain.

Domino Certificate Trust Hierarchy

Sales/North/Acme HR/North/Acme Dev/South/Acme Sales/South/Acme

Users Users Users Users

Key identifier for the OU

User’s Key Identifier and

OU’s Key Identifier and

Key identifier and validity

Cross Certificates, Policies Agents, ECLS & Templates

Information and Data Required To Troubleshoot Key Rollover PMRs.

2. An un-encrypted OS level copy of your Domino Directory.

Steps To Be Taken Prior To Starting The Key Rollover

1 - Make Sure All User Renames Have Completed.

On the Basics tab

Events can be any type

Events can be any severity

Click Save & Close too active the handler.

1. In the Administration client select Configuration Tab  Tools  Certification  ID

2. Expand the ‘Your Identity’ tab and select ‘Your Certificates’.

3 - Ensure Replication Is Functioning Correctly.

4 - Recertify Your Users.

6 – Backup your environment.

1. Your Domino Directory.

2. The Certification Log Database.

4. The ID files for your users, especially the Administrator(s) ID file.

Introducing The GFRT Organisation Test Environment.

Executing The Key Rollover

1 - Rollover the Organisation Certifier.

To rollover the Organisation Certifier complete the following steps.

1. On your Administration client when connected to the Administration Server, select

9. You will then receive the following message

1. Select the Configuration Tab  Tools  Certification  ID Properties.

3. Expand ‘Your Identity’ and select ‘Your certificates’.

1. Select the Configuration Tab  Tools  Certification  ID Properties.

3. Expand ‘Your Identity’ and select ‘Your certificates’.

8. Select your server and click ‘Certify Selected Entries’

In your Administration client:

2. Select the Administration Tab.

Configure The User Rollover Settings In A Security Settings Policy Document.

The Users Are Prompted To Create New Public Keys

The Users Are Prompted To Copy Their ID File

2. Select the user’s name in the view.

Rollover Your Users Without Increasing Their Key Strength

In your Administration client:

4. Click Save & Close.

Rollover Your IBM iNotes Users.

How ID Vault Influences The Key Rollover

ID 'C:\IDs\People\wmcbride.id' failed to upload to vault 'O=OrgVault' on server

ID 'C:\IDs\People\wmcbride.id' failed to upload to vault '' on server

1. Rollover the Organisation and Organisational Unit certifiers.

2. Rollover the Servers.

3. Recertify their users with their rolled over certifiers.

5. Rollover the users.