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
Good question. We can allow a user to use current properties ssl-protocols
and ssl-ciphers even when he wants to use the default security provider.
Here would be a sequence of steps user can to answer:
1) Decide whether you want SSL?
2) Great. Do you want to use
2.a) default ssl context? or
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
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.
>
How does this work if the user wants to use the Trust/KeyStoreManager from
the default security provider but still override other SSL properties such
as ciphers or protocols?
--Jens
On Mon, Aug 13, 2018 at 8:32 AM Sai Boorlagadda
wrote:
> To make it clear about the different options:
>
> 1) if
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
direct
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 (exist
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
provi
> On Aug 9, 2018, at 10:05 AM, Jacob Barrett wrote:
>
>
>
> On Aug 9, 2018, at 9:42 AM, Anthony Baker 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-s
On Aug 9, 2018, at 9:42 AM, Anthony Baker 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 t
>
>
> 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
Based on the review I am amending the proposal as follows:
- Removing the proposed new property 'ssl-use-default-provider'
- Add an ability for GEODE to use default SSLContext
This way users can choose between whether to use default security context
or provide ssl-* parameters to configure it as
All,
GEODE-5338[1], is a feature request to support CA & KEY rotation on the
client application. I am proposing a solution[2] to add a new SSL property (
*ssl-use-default-provider*) to let Geode use default security
provider[3] (either JDK provided provider or a custom provider) to load and
manag
12 matches
Mail list logo
