If an encryption settings definition is compromised, stop using that definition immediately. You must re-encrypt any data encrypted with the compromised definition using a new definition or purge that data from the server. To minimize the risk of data exposure, act quickly on all servers using this definition and act on one server at a time to avoid environment-wide downtime.

Important:

Before removing the compromised encryption settings definition, you should run the encrypt-file --find-encrypted-files command to search for encrypted files on the server. If any files are encrypted with a key tied to the compromised encryption settings definition, those files will no longer be accessible after you remove the definition, potentially preventing the server from starting or from functioning properly. If any encrypted files are found, run encrypt-file --re-encrypt to re-encrypt the files with a different definition before removing the compromised definition.

If you have a compromised encryption settings definition:

  1. Create a new encryption settings definition and make it the preferred definition for new write operations.
  2. Ensure that client traffic is routed away from the compromised server instance.

    If the PingDirectory server is accessed through a PingDirectoryProxy server, then you can set the health-check-state configuration property for any LDAP external server definitions that reference that server to unavailable.

  3. To ensure that external clients are not allowed to perform writes in the PingDirectory server, set the writability-mode global configuration property to internal-only.
  4. Look 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.

    This signals that all outstanding local changes are replicated to other servers.

  5. Stop the PingDirectory server instance.
  6. Delete the replication server database by removing all files in the <server-root>/changeLogDb directory.

    If all local changes have been replicated to other servers, this deletion does not result in any data loss in the replication environment.

  7. Export the contents of all local DB and changelog backends to LDIF.
    Note:

    If you are using the AES256 scheme to store passwords in a reversibly encrypted form, and if any of those passwords are encrypted with the compromised encryption settings definition, you should use the export-reversible-passwords tool rather than the export-ldif tool to perform the LDIF export of the local DB backends. You can use the export-reversible-passwords tool to generate an LDIF file in which all reversibly encrypted passwords are exported in a decrypted form so that when they are re-imported, they are re-encrypted.

  8. Re-import the data from LDIF.

    The data is now encrypted using the new preferred encryption settings definition.

  9. Use the encrypt-file --find-encrypted-files command to find any files that are encrypted with the compromised definition, and use encrypt-file --re-encrypt to re-encrypt them with the new definition.
  10. Export the compromised encryption settings definition from the encryption settings database.

    As a precaution, this backs up the definition in case some remaining data was encrypted with that definition's key.

  11. To prevent the PingDirectory server from using the compromised definition, delete the definition from the encryption settings database.
  12. Start the PingDirectory server instance.
  13. Allow replication to update the server with any changes processed offline.
  14. To re-allow externally-performed write operations, change the value of the global writability-mode configuration property to enable.
  15. To allow client traffic to re-route to that server instance, reconfigure the environment.

    For example, if you changed the value of the health-check-state property in step 2, change it back to dynamically-determined.