Re-encryption in Nexus Repository

For FIPS compliance, all key-passwords used must have at least 112-bit complexity. These must also use a more secure encryption algorithms which will need to be updated. Secrets are complemented by an API key, which is encrypted with the same mechanism. By default, secrets use a password and salt that are not FIPS compliant, so configuring fixed encryption is required.

See FIPS 140-3 Compliance documentation for details.

The following health check warning displays when the default encryption key has not been updated. Use this guide to re-encrypt your secrets to resolve the warning.

Nexus was not configured with an encryption key and is using the Default key

The Nexus Repository upgrade involves applying database scripts to change the schema which the re-encryption mechanism depends on. We recommend avoiding making changes to the encryption while performing an upgrade.

Perform the re-encryption outside of your regular upgrade maintenance plan.

When you already have an encryption configuration file with a fixed encryption and need to update the keys, you must also provide the previous encryption details under the previousFixedEncryption section. Ensure your existing configuration uses secure parameters as defined by FIPS.

Nexus Repository supports configuring the number of iterations used when encrypting passwords and secrets. These settings allow you to control the strength of PBKDF2-based encryption. This configuration is defined in the nexus.properties file and applies to two separate areas:

The encryption iteration properties work in conjunction with their corresponding algorithm properties. Both values must be considered together when configuring encryption behaviour.

Changing the algorithm or iteration value affects how new data is encrypted. Existing data may require re-encryption, depending on the encryption context.

nexus.security.password.algorithm=PBKDF2WithHmacSHA256
nexus.security.password.iterations=12000

nexus.security.secrets.algorithm=PBKDF2WithHmacSHA256
nexus.security.secrets.iterations=12000

When you change the encryption configuration, data created after the change uses the new configuration. Existing data remains encrypted with the previous configuration. To keep your data consistent, re-encrypt existing data after any configuration change.

Encrypted data exists in two tables:

Whenever there is a change to the encryption configuration, you must run the following tasks to re-encrypt the existing data:

PUT /service/rest/v1/secrets/encryption/re-encrypt

curl -u "admin" -X 'PUT' \
  'https://<your-instance-url>/service/rest/v1/secrets/encryption/re-encrypt' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -d '{
  "secretKeyId": "string",
  "notifyEmail": "string"
}'

PUT /service/rest/v1/apikeys/encryption/re-encrypt

curl -u "admin" -X 'PUT' \
  'https://<your-instance-url>/service/rest/v1/apikeys/encryption/re-encrypt' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -d '{
  “algorithmForDecryption”: “Algorithm used before the change“
}'

curl -u "admin" -X 'PUT' \
  'https://<your-instance-url>/service/rest/v1/apikeys/encryption/re-encrypt" \
  -H "Content-Type: application/json" \
  -d '{
    "algorithmForDecryption": "PBKDF2WithHmacSHA1",
    "iterationsForDecryption": 1000,
    "notifyEmail": "[email protected]"
  }'

In a HA cluster all Nexus Repository nodes require access to the secrets found in the JSON file

When using rolling restarts in an HA cluster, temporarily set the active key to null for the first restart. This is necessary as the nodes do not have access to the new key until they are restarted. The secrets file must be accessible by the nodes or the re-encryption task fails.

This allows the nodes to come up with the new secrets file without attempting to use an inactive key. Once all nodes are up, activate the new key using the API, and update your secrets file to reflect this change for subsequent restarts.