Installation Guides › Upgrade Guide › Using FIPS-Compliant Algorithms › How to Re-Encrypt Existing Sensitive Data › Re-encrypt Client Shared Secrets › Use smreghost to Re-encrypt a Shared Secret

Use smreghost to Re-encrypt a Shared Secret

To use smreghost to re-encrypt a shared secret

1. Open a command prompt and run the following command:

   smreghost -i policy_server_ip_address -u administrator_user_name
   -p administrator_password -hn hostname_for_registration -hc host_config_object
   -f path_to_host_config_file -o -cf MIGRATE
   

   -i policy server ip address

   Specifies the IP address of the Policy Server to which the trusted host is registered.

   -u administrator user name

   Specifies the name of the SOA Security Manager administrator with the rights to register a trusted host.

   - p administrator password

   Specifies the password of the administrator who is allowed to register a trusted host.

   -hn hostname for registration

   Specifies the current name of the host that is registered.

   -hc host configuration object

   Specifies the Host Configuration Object configured at the Policy Server.

   -f path to host config file

   Specifies the full path to the file that contains the registration data. The default file name is SmHost.conf.

   Note: If you do not specify a file path, the updated file is saved in the location where you are running smreghost.

   -o

   Overwrites an existing trusted host. If you do not use this argument, you will have to delete the existing trusted host using the Administrative UI. We recommend using smreghost with this argument.

   -cf MIGRATE

   Specifies that smreghost run in FIPS-migration mode.

   Note: When smreghost runs in FIPS-migration mode, the shared secret created and encrypted using FIPS-compliant algorithms.

   smreghost re-registers the trusted host and creates a new shared secret that is encrypted using FIPS-approved algorithms.

2. Open the file that contains the trusted host registration data and verify that a new shared secret is present and prefixed with a FIPS-approved algorithm.

   The shared secret is encrypted using FIPS-compliant algorithms.

   Prefix example: {AES}

You may now re-encrypt sensitive policy and key data in the policy store.