Page History

Proposal is to add a new ssl property (ssl-use-default-providersslcontext) to let Geode use default security provider context (provided by either JDK provided provider or a custom provider). When using SSL, current implementation allows developers to set several ssl-* properties to define paths, types and passwords to keystore and truststores. Geode loads key & trust stores and initializes TrustManagerFactory(TMF) and KeyManagerFactory(KMF) to be used for secure socket management. This imposes certain limitations for developers who wants to bring in their custom implementation for some of the SPIs (Keystore/Truststore SPI, KeyManagerFactory/TrustManagerFactory SPI). Using this proposed new property ssl-use-default-providersslcontext=true, developers can let Geode initialize the TrustMangaer & KeyManager that are default context provided by the system default security provider and not loading them keystores/truststores by using specific filesystem path.

Specifically on client-side, application running in containers , having letting GEODE to read CERTs CERT (key/trust stores) from a filesystem puts a an overhead of re-building container images when these CERTs are rotated in case of security breach or in general for hygienic purposes. So allowing application developers to provide custom implementations of TMF/KMF can support reading CERTs from a non-filesystem based trust and key stores.

Eg: When using Geode on CloudFoundry, applications running using java-buildpack can take advantage of buildpack's "ContainerSecurityProvider", which is a provides a custom implementation for TurstMangaer and KeyManager to read and reads CERTs from CredHubenvironmental variables.

How Geode uses this flag:

geode-core/src/main/java/org/apache/geode/internal/net/SocketCreator.java

...

...

private TrustManager[]SSLContext getTrustManagerscreateAndConfigureSSLContext() throws KeyStoreExceptionGeneralSecurityException, NoSuchAlgorithmException, CertificateException, IOException {

    if (sslConfig.isUseDefaultProvideruseDefaultSSLContext()) {

    TrustManagerFactory tmf =return TrustManagerFactorySSLContext.getInstancegetDefault(TrustManagerFactory.getDefaultAlgorithm());

    tmf.init((KeyStore) null);}

    return tmf.getTrustManagers();

  } else {

    //current implementation of reading truststore and initializing TMF

    ...

    ...

  }

}

private KeyManager[] getKeyManagers() throws KeyStoreException, IOException,

      NoSuchAlgorithmException, CertificateException, UnrecoverableKeyException {

  if (sslConfig.isUseDefaultProvider()) {
SSLContext newSSLContext = getSSLContextInstance();
    KeyManager[] keyManagers = getKeyManagers();
    KeyManagerFactoryTrustManager[] keyManagerFactorytrustManagers = KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm()getTrustManagers();

    keyManagerFactorynewSSLContext.init(nullkeyManagers, trustManagers, null);

 /* use the return keyManagerFactory.getKeyManagers();

  } else {

    //current implementation of reading keystore and initializing KMF

default secure random */);
    ...

    ...

  }

return newSSLContext;
}

...

...

How developers can use this flag on the client:

1. Implement custom provider as per JDK guidlines.

...

Properties pros = new Properties();

props.setProperty(ConfigurationProperties.SSL_ENABLED_COMPONENTS, SecurableCommunicationChannels.SERVER);

props.setProperty(ConfigurationProperties.SSL_REQUIRE_AUTHENTICATION, String.valueOf("true"));

props.setProperty(ConfigurationProperties.SSL_USE_DEFAULT_PROVIDERSSLCONTEXT, String.valueOf("true"));

...