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