000037911 - Change hostnames on a deployed production environment in RSA Web Threat Detection

Document created by RSA Customer Support Employee on Dec 5, 2019
Version 1Show Document
  • View in full screen mode

Article Content

Article Number000037911
Applies ToRSA Product Set: Web Threat Detection
RSA Product/Service Type: Mitigator
RSA Version/Condition: 6.0
IssueWhat are the considerations for changing hostnames on a deployed production environment?
Consider the following:

Changes to the hostname in Universal Conf... (
In the universal conf,  there are many instances of the Hostname... it is dynamically created from other files and scripts... so need to go on what those files are created from... this is not straight forward, and results may not work.

Certificates must have the correct hostname
If you talk about certificates out of the box, then 
silvertail.crt  and the key is doing everything out of the box. It contains the CN as the hostname for SSL handshake and for interprocess communications. So the system uses the silvertail.crt to verify the hostname. With the certificate that the server produced, there will be so much match or get a peer trust issue.


For Data --  The existing data you can keep the old certificates and add new certificates with the new CN (hostname)  if you specify in the configuration. 


Put the new cert with the old cert in the same location directory then configure the new x509 and/or the x509 directory. 
To use any cert that is in that directory, all certs present will be used, so that the old and the new data will be able to be decrypted.


Note: No guarantee this will work.. make the change and see what happens.


What we recommend -- 


The Best Practice is to uninstall and reinstall under the new Hostname. .. 

  • This would be easy to uninstall and reinstall for dev or newly installed system.   
  • However, in a live system, you would have to import the old configuration with all hostnames for the many places hostname is in the universal_conf is changed to the new hostname. This includes adding the new certificate information in universal_conf. 

We might expect that a change the host in Symbols should push out to the entire system but still, certificates are the main problem the silvertail cert and key and the SSL cert for UIServer and also need to consider the kafka certificates and may involve kafka configuration... and Cassandra may have problems. so these use the Java Keystores and may be affected. 

Alternatives -- 
In an enterprise environment, there may be other networking solutions like adding an alias, or tagging, contact your networking organization for advice.