On Thu, 1 Aug 2019 at 13:21, .. ... <[email protected]> wrote:
> Hi Alex, Rob, > > SNI matching can result in list of certificates for particular host. > Certificate alias option specifies always single certificate. Because > certificate alias option is more restrictive, I thought it will have higher > priority than SNI. > No - because if it always used the alias then there'd be no point in doing SNI matching in addition :-) . The SNI matching is designed for the case where you have multiple distinct hostnames (with different certs) and you want to serve the correct cert for the given hostname. The way it works now is that it only uses the alias if there is no match. If there is an SNI match, it will only return a valid cert (so it will not return a new cert if it is not yet valid). If the cert is not valid or compromised then you really should remove it from the keystore. -- Rob > > For instance corner case where selecting certificate with SNI enabled could > be helpful: > * Host certificate will expire in one month > * New host certificate is created, added to keystore with different alias > and distributed to client > * Client for some reason wants to use new certificate before old > certificate expires (for instance certificate was compromised, ...) > * Old certificate have to be physically removed from keystore, because both > certificates are valid and broker picks first one. If "Certificate alias" > would have higher priority, then certificate alias can be set in webgui > without touching any file on filesystem > > But this situation can be also solved by disabling SNI in webgui and broker > will offer correct certificate (if certificate alias set). > > Maybe it will be clearer if options "SNI host matching" and "Certificate > alias" will be exclusive -> Certificate alias can be set only if "SNI host > matching" is disabled. > > Regards, > Tomas > > On Thu, Aug 1, 2019 at 10:31 AM Oleksandr Rudyy <[email protected]> wrote: > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
