PingDirectory

Re-encrypting data in the database

If you update the server to use a new preferred encryption settings definition, that new definition is used for all subsequent data encryption, but existing data remains encrypted with an older key.

In many cases, this can be acceptable. Records in the replication database or the LDAP changelog that were encrypted with an old key are eventually removed in accordance with the configured purge settings, and entries in backends are upgraded to use the new key as they are updated by clients.

However, there can be cases, such as if you suspect that an existing key might have been compromised, in which you want to immediately transition to using a new definition. To do this, you must use the encryption-settings create command to add the desired new encryption settings definition to the settings database on all servers or alternatively, create the new definition on one server, export it from that instance, and import it into all of the other instances. You can then use the encryption-settings set-preferred command to make the new definition the preferred definition across all instances.

Before removing a 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.

Complete the following process for each instance, one instance at a time, in the topology:

  1. To disable replication for all backends and remove the server from the replication topology, use dsreplication disable.

  2. Stop the instance so that its data will not change during the process of converting to the new key.

  3. To export the contents of all encrypted backends, those backed by the Berkeley DB Java Edition database, to LDIF, use the export-ldif command. If the LDAP changelog is enabled, then also export its contents to LDIF using the same process. Make sure that the LDIF exports are encrypted (see Encrypting LDIF exports) to keep them secure.

  4. To re-import the LDIF data into the appropriate backends, use the import-ldif command.

  5. Remove the changelgoDb directory in the server instance root, which holds the replication database not the db/changelog directory, which holds the database for the LDAP changelog.

  6. Start the server.

  7. To add the server back into the replication topology and verify that changes are properly replicated between that instance and other servers in the topology, use dsreplication enable.