Exactly. I would have assumed #2 is bringing in default context if the user
does not specific keystore and truststore. But unfortunately, the current
code loads keystore from "{user.home}/.keystore" and so the proposal for
this new property.
We should probably disable loading from user.home if not specified in 2.0Sai On Mon, Aug 13, 2018 at 8:48 AM Jinmei Liao <jil...@pivotal.io> wrote: > Doing #2 an #3 alone would fix GEODE-5338, right? We don't really need this > new option. > > On Mon, Aug 13, 2018 at 8:32 AM Sai Boorlagadda <sai.boorlaga...@gmail.com > > > wrote: > > > To make it clear about the different options: > > > > 1) if ssl-enabled-component & ssl-use-default-context is configured then > > use default SSL context. > > 2) if ssl-enabled-component & no other ssl-* properties are configured > then > > configure SSL context by loading truststore and keystore from user home > > directory. > > 3) if ssl-enabled-component & ssl-* properties are configured then > > configure SSL context as configured by user. > > > > While #2 and #3 are existing behavior, #1 is implemented as part of > current > > proposal for GEODE-5338. > > > > On Mon, Aug 13, 2018 at 8:25 AM Sai Boorlagadda < > sai.boorlaga...@gmail.com > > > > > wrote: > > > > > I missed follow up emails on this thread, for some reason my email > client > > > didn't show there were new messages on this thread. Like Jinmei said, a > > > user has to first enable SSL by configuring ssl-enable-component and > then > > > chose between using default context or using specific > > > keystore/trustsore (existing implementation). > > > > > > Also, I am dropping the idea of making it a new default to use default > > SSL > > > context as it will break backward compatibility. > > > > > > On Thu, Aug 9, 2018 at 10:52 AM Jinmei Liao <jil...@pivotal.io> wrote: > > > > > >> let me see if my understanding is correct: if ssl-enabled-component is > > >> none, then we would accept non-ssl connections, no ssl context will be > > >> used. if ssl-enabled-component is something other than "none", but we > > don't > > >> specify any other ssl-* configurations, then we use the default ssl > > context > > >> provided by JDK, any customization to the JDK's ssl context (either by > > >> installing a custom provider or keystore/truststore installed in jdk's > > >> path) will be used this way. But we do specify any other ssl-* > > >> configurations, then we use our usual way of loading the ssl context. > > >> > > >> On Thu, Aug 9, 2018 at 10:33 AM Anthony Baker <aba...@pivotal.io> > > wrote: > > >> > > >>> > > >>> > > >>> > On Aug 9, 2018, at 10:05 AM, Jacob Barrett <jbarr...@pivotal.io> > > >>> wrote: > > >>> > > > >>> > > > >>> > > > >>> > On Aug 9, 2018, at 9:42 AM, Anthony Baker <aba...@pivotal.io> > wrote: > > >>> > > > >>> >>> > > >>> >>> > > >>> >>> I would like to also get consensus on defaulting GEODE's behavior > > to > > >>> always > > >>> >>> use default SSL context instead of introducing a new parameter > > >>> >>> 'ssl-use-default-sslcontext'. If user's have specified any > existing > > >>> ssl-* > > >>> >>> props then the current implementation is exercised (ie to > configure > > >>> the > > >>> >>> context as per provided properties). > > >>> >>> > > >>> >> > > >>> >> If geode is always configured to use the default SSL context, how > do > > >>> we know to when to accept SSL v non-SSL connections? > > >>> >> > > >>> > > > >>> > The enable ssl properties. > > >>> > > > >>> > > >>> Sorry I’m missing something. If the only time we accept SSL > > connections > > >>> is when you enable geode ssl-* properties, what is the point of > > enabling > > >>> the default SSL context by default? > > >>> > > >>> Anthony > > >>> > > >>> > > >> > > >> -- > > >> Cheers > > >> > > >> Jinmei > > >> > > > > > > > > -- > Cheers > > Jinmei >
