If an encryption-settings definition becomes compromised such that an unauthorized individual obtains access to the encryption key, then any data encrypted with that definition is also vulnerable because it can be decrypted using that key. It is very important that the encryption-settings database be protected (for example, using file permissions or file system ACLs) to ensure that its contents remain secure.

In the event that an encryption-settings definition is compromised, stop using the definition immediately. Any data encrypted with the compromised key should be re-encrypted with a new definition or purged from the server. This can be done on one server at a time to avoid an environment-wide downtime, but it should be completed as quickly as possible on all servers that had used that definition at any point in the past in order to minimize the risk of that data becoming exposed.

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").