Just for info, I have now updated the default behaviour of the keystore to always return a valid certificate (if one is available), and to use (if available) the host name information in the client's connection to pick a certificate which matches the expected address (work done under QPID-7567).
-- Rob On 27 October 2017 at 16:12, Vavricka <vavricka.to...@gmail.com> wrote: > rgodfrey wrote > > On 27 October 2017 at 10:43, Vavricka < > > > vavricka.tomas@ > > > > wrote: > > > > 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 > > I misunderstood how SSL handshake works. Because server offers certificate > first, server can't know what certificate client have. > > Case 2. is now irrelevant and I expect same Java broker behavior as today. > > Thanks for explanation. > > Vavricka > > > > -- > 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 > >
