|Applies To||RSA Product Set: Web Threat Detection|
RSA Product/Service Type: Mitigator
RSA Version/Condition: 6.0
|Issue||What are the considerations for changing hostnames on a deployed production environment?|
Consider the following:
Changes to the hostname in Universal Conf... (Universal_conf.py)
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. ..
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.
In an enterprise environment, there may be other networking solutions like adding an alias, or tagging, contact your networking organization for advice.