Last Modified: Mar 12, 2019
See more info
Known Affected Versions:
11.5.1, 11.5.1 HF1, 11.5.1 HF10, 11.5.1 HF11, 11.5.1 HF2, 11.5.1 HF3, 11.5.1 HF4, 11.5.1 HF5, 11.5.1 HF6, 11.5.1 HF7, 11.5.1 HF8, 11.5.1 HF9, 11.5.2, 11.5.2 HF1, 11.5.3, 11.5.3 HF1, 11.5.3 HF2, 11.5.4, 11.5.4 HF1, 11.5.4 HF2, 11.5.4 HF3, 11.5.4 HF4, 11.5.5, 11.5.6, 11.5.7, 11.5.8, 11.5.9, 12.0.0, 12.0.0 HF1, 12.0.0 HF2, 12.0.0 HF3, 12.0.0 HF4
Opened: May 26, 2015
If a BIG-IP system uses in Secure Vault to encrypt secure fields, you cannot load that SCF to another BIG-IP system.
SCF load fails.
This occurs when an SCF originates on a BIG-IP system whose secure fields are encrypted using Secure Vault. The reason is that the Master Key to the Secure Vault has been encrypted with the Unit key of the originating BIG-IP system. The Unit key is unique to each system.
Although in this case, you cannot load an SCF from one device to another without intervention, the admin can now change the master key and then successfully load the configuration onto a different device. 1. Before taking the SCF (and related tar file) to a different system, set the master key from a passphrase using the following command: tmsh modify sys crypto master-key prompt-for-password. 2. On the system where the SCF will be restored, load the SCF. (Here, it fails to load due to encrypted attributes which cannot be decrypted.) 3. On the new system with the failed SCF load, set the master key using the previously specified passphrase, by running the command: tmsh modify sys crypto master-key prompt-for-password. 4. Load the configuration with the command: tmsh load sys config. The configuration loads and the encrypted attributes are accessible.