I can imagine these situations where it can be helpful. 1.
* There is active/passive cluster (provides a fully redundant instance of each node, which is only brought online when its associated primary node fails) environment where Java broker is running on node1 * Shared drive is used for keystore and truststore * In keystore there are certificates for each node * node1 - CN=hostname1, alias hostname1 * node2 - CN=hostname2, alias hostname2 ... * Unless "transport.verifyHost=false" is specified in connection string, clients can connect only with correct certificates for each node * When cluster node is relocated to node2, Java broker starts on node2 and loads keystore from shared drive * If client cannot connect with certificate for node1, he can try node2 and if Java broker is running on node2, he can successfully connect to broker 2. * Certificate with "CN=hostname" and alias "hostname" is valid from 30.10.2014 10:00 to 30.10.2017 10:00 * At 26.10.2017 certificate with "CN=hostname" and alias "hostname_2" with validity from 28.10.2017 10:00 to 28.10.2020 is added to server keystore and sent to client * Client can use both certificates in transitional period 28.10.2017 10:00 - 30.10.2017 10:00. Because there is transitional period client can prepare new certificate in his software * In maintenance batch at 30.10.2017 24:00 is expired certificate removed and only new certificate is present in keystore -- Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
