Tomas, Thanks for clarification. I am actually curious about your keystore setup. Why do you need multiple valid certificates with matching SNI host name? Perhaps, I missing some useful use cases. In that case, I can update keystore implementation to use alias to pick up the right certificate among several valid ones.
The keystore documentation needs to be updated to highlight how it works with "SNI host name matching" and alias configured. Kind Regards, Alex On Wed, 31 Jul 2019 at 11:33, .. ... <[email protected]> wrote: > Hi Alex, > > I thought that property "Certificate alias" have higher priority than "SNI > host name matching". > > If I understand it correctly, there is no way to tell broker which > certificate alias broker should use if there are multiple valid > certificates matching SNI hostname and "SNI host name matching" is set to > true. > > Now when I know how certificate selection works, I think there is no > problem. I will set "SNI host matching" to false and broker will offer > certificate specified by "Certificate alias". > > Thanks for clarifying. > > Regards, > Tomas > > On Wed, Jul 31, 2019 at 2:29 AM Oleksandr Rudyy <[email protected]> wrote: > > > Hi Tomas, > > > > I quickly looked through the implementation of FileKeyStore and how > aliases > > used. > > The code looks Ok to me. > > > > Could you please provide more details about your alias problem? > > > > Do you use "SNI host name matching"? > > > > Please note that with the latter set to "true", the SNI host name is used > > to pick up a certificate. > > If there are multiple certificates matching SNI host name, the first > valid > > one is selected. If there is no valid certificate, but a number of > invalid > > certificates matching SNI is found, the first invalid is selected. The > > alias is used only when store does not have valid or invalid certificates > > matching SNI host name. > > > > I will appreciate if you could provide more information about your alias > > issue. > > > > Kind Regards, > > Alex > > > > [1] > > > > > http://qpid.2158936.n2.nabble.com/Java-Broker-Select-certificate-from-broker-keystore-td7673701.html > > > > On Tue, 30 Jul 2019 at 10:03, .. ... <[email protected]> wrote: > > > > > Hi Alex, > > > > > > > > > > > > I personally think explicit reload is good approach. With explicit > reload > > > we can control when keystore/truststore will be reloaded. In case of > > > automatic background checks, attacker can compromise truststore and > > > compromised truststore will be automatically reloaded by broker. > > > > > > > > > > > > Note: Certificate aliases are broken in 7.1.x as well as in master. > > > > > > > > > > > > Regards, > > > > > > Tomas > > > > > > > > > > > > <quote author="Oleksandr Rudyy"> > > > > > > Hi Tomas, > > > > > > > > > > > > The reload operation in FileKeyStore only updates certificate data as > > they > > > > > > are cached. The key managers are re-created from keystore every time on > > > > > > ports opening. That's why reload of FileKeyStore is not really > required. > > > > > > For the file trust stores, the trust managers are cached and updated by > > > > > > reload operation. > > > > > > > > > > > > Potentially, instead of having explicit reload operations, the > background > > > > > > checks can be implemented to watch for keystore file modification in > > order > > > > > > to update all cached data promptly. > > > > > > What do you think about this approach? > > > > > > > > > > > > Thanks for providing the link to discussion about certificate aliases. > > I'll > > > > > > check what broke it in 7.1. > > > > > > > > > > > > Kind Regards, > > > > > > Alex > > > > > > > > > > > > On Mon, 29 Jul 2019 at 14:34, .. ... <<email>vavricka.tomas@ > > > </email>> > > > wrote: > > > </quote> > > > > > > On Mon, Jul 29, 2019 at 7:40 PM Oleksandr Rudyy <[email protected]> > > wrote: > > > > > > > Hi Tomas, > > > > > > > > The reload operation in FileKeyStore only updates certificate data as > > > they > > > > are cached. The key managers are re-created from keystore every time > on > > > > ports opening. That's why reload of FileKeyStore is not really > > required. > > > > For the file trust stores, the trust managers are cached and updated > by > > > > reload operation. > > > > > > > > Potentially, instead of having explicit reload operations, the > > background > > > > checks can be implemented to watch for keystore file modification in > > > order > > > > to update all cached data promptly. > > > > What do you think about this approach? > > > > > > > > Thanks for providing the link to discussion about certificate > aliases. > > > I'll > > > > check what broke it in 7.1. > > > > > > > > Kind Regards, > > > > Alex > > > > > > > > On Mon, 29 Jul 2019 at 14:34, .. ... <[email protected]> > wrote: > > > > > > > > > Hi Alex, > > > > > > > > > > > > > > > Thanks a lot for very fast implementation, I can confirm reloading > of > > > > > keystore/truststore is working as expected. > > > > > > > > > > > > > > > Note: Keystore is reloaded everytime I use "Update TLS", I do not > > have > > > to > > > > > reload keystore itself (truststores have to be reloaded before > > "Update > > > > TLS" > > > > > is called). > > > > > > > > > > > > > > > Regarding issue with keystore's certificate alias there is > discussion > > > > about > > > > > it - > > > > > > > > > > > > > > > > > > > > http://qpid.2158936.n2.nabble.com/Java-Broker-Select-certificate-from-broker-keystore-td7673701.html > > > > > , it maybe help you out. > > > > > > > > > > > > > > > Qpid Broker-J 8.0.0-SNAPSHOT - last commit - > > > > > ca6626ee2a5f317ed0426b2219236364b859969f > > > > > > > > > > > > > > > Regards, > > > > > Tomas > > > > > > > > > > > > > > >
