The Domino Certificate Authority Key Rollover Process. Author: Graham Farrell IBM Domino server Support Engineer

Transcription

1 The Domino Certificate Authority Key Rollover Process Author: Graham Farrell IBM Domino server Support Engineer 1

2 Introduction 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 Key Rollover Without ID Vault Steps To Be Taken Prior To Starting The Key Rollover Make Sure All User Renames Have Completed Log And Correct Public Key Mismatches Ensure Replication Is Functioning Correctly Recertify Your Users Determine If You Will Rollover Or Just Recertify Your Servers and Users, Backup your environment Introducing The GFRT Organisation Test Environment Executing The Key Rollover Rollover the Organisation Certifier Rollover the Organisation Unit Certifiers Rollover The Servers Rollover Your Users Key Rollover With ID Vault How ID Vault Influences The Key Rollover Steps To Be Taken Prior To Starting The Key Rollover Make Sure All User Renames Have Completed Disable Public Key Checking Log And Correct Public Key Mismatches Ensure Replication Is Functioning Correctly Ensure Your Users Local ID and Vaulted ID Have The Same Password Backup your environment Introducing The GFVRT Organisation Test Environment Executing The Key Rollover Rollover the Organisation Certifier Rollover the Organisation Unit Certifiers Rollover The Servers Recertify Your Users Recreate The Vault Trust And Password Reset Certificates Rollover Your Users Conclusion

3 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 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

4 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 reestablish 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

5 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: 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

6 /Acme North/ Acme Servers South/ Acme 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

7 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 selfsigned certificate 7

8 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

9 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

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

11 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 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

12 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

13 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

14 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 field 1 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

15 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 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

16 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

17 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

18 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 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 code stream and the organisation has not set up an ID Vault to harvest and manage their users ID files. 18

19 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 01.ibm.com/support/docview.wss?uid=swg 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

20 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

21 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

22 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

23 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

24 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

25 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. 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 the first of your Organisational Unit Certifier that you wish to rollover 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, 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

26 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

27 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

28 To view the new public key identifiers for the Organisation Unit certifier complete the following steps on your Administration client. 1. Select the Configuration Tab Tools Certification ID Properties. 2. Select the ID file for the Organisational Unit certifier 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 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

29 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

30 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

31 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

32 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

33 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

34 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

35 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

36 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

37 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

38 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

39 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. In your Administration client: 1. Select the security settings document, click Edit Settings and elect the Keys and Certificates Tab. 2. Set the Maximum allowable age for key to its minimum value of 180 days. 3. Set the Don t automatically generate a new key before field to yesterday s date. 4. Click Save & Close. 5. Select the Policy document and click Edit Policy and then Save & Close to update the policy document. 39

40 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

41 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 FP6. Domino 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

42 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

43 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

44 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

45 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

46 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 or log to a database every time the error appears on the server console. 46

47 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

48 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

49 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

50 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 field 2 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

51 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 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/ :52:11 PM ID for 'Kate Farrell/North/GFVRT' (IP Address :1295) in vault 'O=OegVault' was not downloaded because the wrong password was supplied. Password. (Passwords are case sensitive - be sure to use correct upper and lower case.) Error: Wrong 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

52 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 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 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

53 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

54 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 keyset. 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. 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

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

56 4. Select the first certificate entry and click on the Advanced Details button. 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

57 7. As you can see the Key Identifier and Issuer Key identifier of 19G1B 5NN2Y K5BGN DGV4P 11F4W A24BD, with a key strength of 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

58 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

59 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. 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 the first of your Organisational Unit Certifier that you wish to rollover 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, 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

60 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

61 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. 1. Select the Configuration Tab Tools Certification ID Properties. 2. Select the ID file for the Organisational Unit certifier 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 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

62 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

63 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

64 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

65 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

66 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

67 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. 6. Click Save & Close. 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

68 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

69 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

70 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

71 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

72 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

73 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

74 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

75 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