---
title: Re-encrypting data in the database
description: 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.
component: pingdirectory
version: 11.0
page_id: pingdirectory:pingdirectory_security_guide:pd_sec_re_encrypt_database
canonical_url: https://docs.pingidentity.com/pingdirectory/11.0/pingdirectory_security_guide/pd_sec_re_encrypt_database.html
revdate: September 19, 2023
---

# 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`.