The recommended process for responding to a compromised encryption settings definition is as follows:

  1. Create a new encryption-settings definition and make it the preferred definition for new writes.
  2. Ensure that client traffic is routed away from the server instance to be updated. For example, if the Directory Server is accessed through a Directory Proxy Server, then you may set the health-check-state configuration property for any LDAP external server definitions that reference that server to have a value of unavailable.
  3. Ensure that external clients are not allowed to write operations in the directory server instance. This may be accomplished by setting the writability-mode global configuration property to have a value of internal-only.
  4. Wait for all outstanding local changes to be replicated out to other servers. This can be accomplished by looking at the monitor entries with the ds-replication-server-handler-monitor-entry object class to ensure that the value of the update-sent attribute is no longer increasing.
  5. Stop the directory server instance.
  6. Delete the replication server database by removing all files in the changeLogDb directory below the server root. As long as all local changes have been replicated out to other servers, this will not result in any data loss in the replication environment.
  7. Export the contents of all local DB and changelog backends to LDIF. Then, re-import the data from LDIF, which will cause it to be encrypted using the new preferred encryption settings definition.
  8. Export the compromised key from the encryption settings database to back it up in case it may be needed again in the future (e.g., if some remaining data was later found to have been encrypted with the key contained in that definition). Then, delete it from the encryption settings database so that it can no longer be used by that directory server instance.
  9. Start the directory server instance.
  10. Allow replication to bring the server back up-to-date with any changes processed while it was offline.
  11. Re-allow externally-initiated write operations by changing the value of the global writability-mode configuration property back to enabled.
  12. Re-configure the environment to allow client traffic to again be routed to that server instance (e.g., by changing the value of the "health-check-state" property in the corresponding LDAP external instance definitions in the Directory Proxy Server instances back to "dynamically-determined").