Page History

Proposal is to add a new ssl property (ssl-use-default-provider) to let Geode use system default security provider (either JDK provided provider or a user provided custom provider). When using SSL, current implementation allows developers to set several ssl-* properties to define paths, types and passwords to keystore and truststoretruststores. Geode loads key and & 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-provider=true, developers can let Geode initialize the TrustMangaer & KeyManager that are provided by the system default and not loading them using specific path.

Specifically on client-side , in a container worldapplication running in containers, having GEODE to read CERTs from a filesystem puts a overhead of re-building application container images when these CERTs are rotated for security(Hygenic) in case of security breach or in general for hygienic purposes. So allowing application developers can 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 provides a “ContainerSecurityProvider” with a buildpack can take advantage of buildpack's "ContainerSecurityProvider", which is a custom implementation for TurstMangaer and KeyManager to read CERTs from CredHub.

...