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 > > > > > >
