Hi Rob, Thanks for detailed explanation of rationale behind current implementation..
I guess, that Tomas is looking for a way to be able to select certificate from multiple with matching SNI host name. It feels like he needs an alias per host name rather than just one default alias. I am speculating, as I am not sure what are the real use cases here. Kind Regards, Alex On Wed, 31 Jul 2019 at 17:36, Rob Godfrey <[email protected]> wrote: > On Wed, 31 Jul 2019 at 17:37, Oleksandr Rudyy <[email protected]> wrote: > > > 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 current design is quite deliberate - I don't think it makes sense to > apply the alias if SNI matching in in effect and a match has been made. If > the store has certs for hosts A, two certs for B and two certs for C ... > and the alias point at one of the certs for C... what should be done in the > case where a connection is made that matches host B... surely it doesn't > make sense to use one of the certs for C (which prioritising the alias > would imply). Basically if you are using SNI matching I think that always > needs to take priority, and you would only use the alias in the case there > is no match. > > -- Rob > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > >
