Manual Chapter :
Additional Information about BIG-IQ Centralized Management
Applies To:
Show VersionsBIG-IP APM
- 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0
BIG-IP LTM
- 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0
BIG-IP AFM
- 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0
BIG-IP DNS
- 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0
BIG-IP ASM
- 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0
Additional Information about BIG-IQ Centralized Management
Creating a backup of the nShield RFS
Before you back up the RFS, make sure that the
nShield Remote File System (RFS) server is installed on your network.
You back up the
/shared/nfast/kmdata/local/
directory
of the RFS to a secure location, so that you can recover the RFS state, if needed. The
RFS contains all of the nShield keys.- If the RFS is not installed on the BIG-IP system, rename the/shared/nfastdirectory to/shared/nfast.org.This directory can be used to recover old data, if necessary.
- Follow the nShield best practices for backing up the RFS server.
Upgrading the BIG-IP software when using the nShield HSM
After a BIG-IP system software or hotfix upgrade, you must run the nShield
client setup script to restore your default nShield configuration. Any local keys
and certificates you loaded into the BIG-IP system before upgrading (using the
command
tmsh install sys crypto
)
appear in the upgrade partition, but they are usable only after you run the nShield
client setup script. If you are restoring the nShield client on a VIPRION system,
you run the configuration script only on the primary blade, and then the system
propagates the configuration to the additional active blades.If you will
need CSRs, keys, or certs that were not loaded into the BIG-IP system, before you
upgrade, copy the files into the
/shared
directory. After the
upgrade, copy them back to their appropriate directories in the new partition:
/config/ssl/ssl.key/
,
/config/ssl/ssl.crt
, or
/config/ssl/ssl.csr
.- Log in to the command-line interface of the BIG-IP system using an account with administrator privileges.
- Run one of these scripts, using the arguments that are appropriate for your configuration:
- If the BIG-IP is an RFS server in addition to being a nShield client, use:nethsm-thales-rfs-install.shandnethsm-thales-install.sh
- If the BIG-IP is only a nShield client use:nethsm-thales-install.sh
The protected keys, which are stored in
/opt/nfast/kmdata/
, are
available in the new partition, regardless of whether the keys and certs were loaded
into the BIG-IP system.Uninstalling nShield components from the BIG-IP system
If
you no longer need to use the nShield on a BIG-IP system, you should uninstall the
files.
- Log in to the command-line interface of the system using an account with administrator privileges.
- Uninstall the client and clean up.nethsm-thales-install.sh -u [-v]
Replacing a broken nShield HSM without breaking existing
keys
You can replace a broken nShield HSM without
destroying existing keys.
- Turn on the new HSM, and give it an IP address, netmask, and default route.nethsm-thales-install.sh -u [-v]
- Reconfigure the RFS, so that you can point the HSM to it. If the RFS is a BIG-IP system, usenethsm-thales-rfs-install.sh --hsm_ip_addr=<new HSM IP>. When the script asks if you want to uninstall, typeyes. When the script asks if you want to overwrite the config, typeyes. When the script asks if you want to use the existing Security World, typeyes.
- Using the front panel on the HSM, configure the HSM to know its RFS. Once this is done, using the front panel again, add at least the BIG-IP system and the RFS to the HSM as clients.
- Using the front panel of the HSM and a quorum of the ACS, load the Security World onto the HSM.
- On the RFS, unenroll the old HSM, because otherwise it will still show up in enquiry results.nethsmenroll --force -r <old HSM IP> <old HSM ESM> <old HSM hash>Note that this requires the ESM and HSM hash from the broken machine. The commandanonknetiwill not work because the old HSM is broken or already removed from the network. This needs to be done even if the RFS is a BIG-IP system and thenethsm-thales-rfs-install.shcommand was used.
- Rerun the install script on any BIG-IP systems that use the HSM. When that script asks if you want to uninstall, typeyes. When that script asks if you want to backup, type whichever you prefer.
- On each BIG-IP system, unenroll the old HSM, because it will still show up in enquiry results.nethsmenroll --force -r <old HSM IP> <old HSM ESM> <old HSM hash>Note that this requires the ESM and HSM hash from the broken machine. The commandanonknetiwill not work, since the old HSM is broken or already removed from the network.
nethsm-thales-install.sh utility options
The
nethsm-thales-install.sh
utility
includes these options:Option |
Description |
---|---|
-h |
Displays help. |
-u |
Uninstalls and cleans-up the nShield software. |
-v |
Prints verbose output about operations. |
--hsm_ip_addr=<ip_addr> |
nShield HSM IP address(es). For multiple HSMs, use a
double-quoted value with space-separated IP addresses (such as --hsm_ip_addr="10.10.10.100.10.10.10.101" ). |
--hsm_partition_name=<partition name> |
nShield HSM partition name. For a single partition, use a
double-quoted value. For example: --hsm_partition_name="loadshared accelerator" . For
multiple partitions, use a double-quoted value with a colon-separated
partition name. For example: --hsm_partition_name="softcard1:softcard2:loadshared
accelerator" . To receive a partition name, use the nShield
utility "ckinfo" to get
the partition name after "label" under the "CK_TOKEN_INFO" section. You can ignore the trailing
spaces of the label name. |
--hsm_partition_pwd=<password> |
The nShield HSM partition password. This must be the same for
all HSMs being used in a High Availability (HA) configuration. For
multiple partitions, use a double-quoted value with a space-separated
partition password.The passwords should be in the same order as the
partition. For example: --hsm_partition_pwd="abc xyz uvw" . |
--rfs_interface=<interface_name> |
Interface identifier for the local Remote File System (RFS) server. Default is the
management interface (eth0). |
--protection=<protection_type> |
Indicates which type of key protection to use. Valid options are [m]odule, [o]cs, or
[s]oftcard. When this option is not used, the protection defaults to
module protection. |
--verbose=<level> |
Indicates message verbosity level. The default value is zero, and all
levels greater than zero indicate verbose output. |
nethsm-thales-rfs-install.sh utility options
The
nethsm-thales-rfs-install.sh
utility
includes these options:Option |
Description |
---|---|
-h |
Displays help. |
--u |
Uninstalls nShield software and cleans up nShield
directories. |
-v |
Prints verbose output about the executing operations. |
--hsm_ip_addr=<ip_addr> |
nShield HSM IP address(es). For multiple HSMs, use a
double-quoted value with space-separated IP addresses (such as --hsm_ip_addr="10.10.10.100.10.10.10.101" ). |
--interface=<interface_name> |
Interface identifier of BIG-IP to be used as nShield HSM Client
(eth0). The default is the management interface. |
--num_threads=<threads> |
Indicates the number of threads pkcs11d will use. The default is 20. |
--rfs_interface=<interface_name> |
Local Remote File System (RFS) server interface name (eth0). |
--rfs_ip_addr=<ip_addr> |
Remote RFS server IP address. |
--rfs_username=<ssh_username> |
Remote RFS server username for SSH login. |
--protection=<protection_type> |
Indicates which type of key protection to use. Valid options are
[m]odule, [o]cs, or [s]oftcard. When this option is not used, the
protection defaults to module protection. |
--verbose=<level> |
Indicates message verbosity level. The default value is zero, and all
levels greater than zero indicate verbose output. |