Juan, Let me try and answer just to ensure that *I* fully understand the use case.
>From an 'alias' POV this could be seen as having the ability for a *single* component (locator, server, etc) to have multiple (dynamic) aliases. So, depending on where the connection originated *from* a particular certificate is chosen. Currently we only have the ability to associate a single certificate with an individual component. --Jens On Fri, Nov 1, 2019 at 10:51 AM Ju@N <jujora...@gmail.com> wrote: > Hello Alberto, > > I'm not particularly knowledgeable on this subject so I might be missing > something, but with Geode you can independently configure SSL for specific > system components, can't you just use multiple alias to achieve your use > case as described here [1]?. > > *>> The situation is the following: when SSL is enabled, we would like to > use multiple certificates in locators and servers: one certificate for > communication inside one geographical site, and another for the > communication happening between geographical sites. The approach we took is > to use the default SSL context and implement our own Java Security > Provider.* > Here you would use *cluster *as the alias to configure the SSL settings > used for communications within one geographical site, and *gateway *as the > alias to configure the particular SSL settings to be used for > communications across sites. Would that work for you?. > > Cheers. > > [1]: > > https://geode.apache.org/docs/guide/110/managing/security/implementing_ssl.html > > > On Fri, Nov 1, 2019 at 1:37 PM Anthony Baker <aba...@pivotal.io> wrote: > > > Just checking, is anyone familiar enough with SSL to comment on the > > proposed change? > > > > Anthony > > > > > > > On Oct 29, 2019, at 2:44 AM, Mario Ivanac <mario.iva...@est.tech> > wrote: > > > > > > Hi, > > > > > > We are trying to find a solution for an situation we have. Below is the > > explanation of the issue, as well as a proposed way forward. We would > > appreciate comments from the community regarding this approach. Also, > > suggestions for a different approach to solve this issue would be > welcome. > > > > > > The situation is the following: when SSL is enabled, we would like to > > use multiple certificates in locators and servers: one certificate for > > communication inside one geographical site, and another for the > > communication happening between geographical sites. The approach we took > is > > to use the default SSL context and implement our own Java Security > Provider. > > > > > > The client side can, from the security provider, easily distinguish > > which certificate to use (just check if you are initiating a connection > > towards an IP listed in gemfire.remote-locators). The thing we are > missing > > is a criteria based on which we can choose the certificate on the server > > side of the connection. Explanation: Once the handshake starts, a > > ClientHello message is sent from the peer acting as a client in that > > connection (be it a geode server or a geode locator). When the > ClientHello > > is received on the server side, we can’t always read the real originating > > IP (keeping the originating IP is sometimes not possible in cloud native > > environments), so we can’t be sure whether the message originated from > the > > same geographical site or from another. We are left only with the > > information inside the ClientHello message. The default ClientHello > message > > doesn’t contain information based on which we can conclude which site the > > message came from and which certificate to use. > > > > > > Our proposal is to add the server_name extension in the ClientHello > > message. The content of that extension would be the distributed system ID > > of the site where the ClientHello originated. This way we could compare > the > > distributed system ID in the ClientHello message with the ID of the site > > where the message is received. > > > > > > One issue with this approach is that the usage of the extension > wouldn’t > > be completely in line with the RFC< > > https://tools.ietf.org/html/rfc6066#page-6> description: we would be > > inserting client information instead of the targeted server name. Still, > > since this extension is otherwise of no use in Geode, and this approach > > doesn’t present a security risk (we would be sharing the distributed > system > > ID, which doesn’t look dangerous), we see this as a potential way to go. > > > > > > > > > > > > > > > -- > Ju@N >
