On 27 October 2017 at 10:43, Vavricka <vavricka.to...@gmail.com> wrote:
> 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 > > OK - so the current keystore solution doesn't do anything smart at all about having certificates for different hostnames in the same keystore. I do think this would be a nice addition. > 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 > > > In the period 28.10.2017 10:00 - 30.10.2017 10:00; both certificates are valid... the broker can't really know which is "preferred" by the client, I would think that we should always go with the one with the most distant expiry simply to avoid issues where we are getting very close to the expiry time of the older certificate (i.e. if we are within a minute, then you run the risk of clock drift between the client and server causing the served certificate to appear invalid. Is this your expectation too? -- Rob > > > > -- > 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 > >
