Jon Marius Venstad created ZOOKEEPER-4828: ---------------------------------------------
Summary: Minor 3.9 broke custom TLS setup with ssl.context.supplier.class Key: ZOOKEEPER-4828 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4828 Project: ZooKeeper Issue Type: Bug Reporter: Jon Marius Venstad We run embedded ZooKeeper in Vespa, and use a custom TLS stack, where we, e.g., do additional validation and authorisation in our TLS trust manager, for client certificates. The changes in https://github.com/apache/zookeeper/commit/4a794276d3d371071c31f86c14da824fdd2e53c0, done for ZOOKEEPER-4622, broke the `ssl.context.supplier.class configuration parameter`, documented in the ZK admin guide (https://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_configuration). Consequently, current code (3.9.2) now enforces a file-based key and trust store for _any TLS_, which is not an option for us. I looked at two ways to fix this: 1. Add new configuration parameters for _key_ and _trust_ store _suppliers_, as an alternative to the key and trust store _files_ required in the new (with 3.9.0) ClientX509Util code—this adds another pair of config options, of which there are already plenty, and the user is stuck with the default JDK `Provider` (optional argument to SSLContext.getInstance(protocols, provider); it also lets users with a custom key and trust store use the native SSL support of Netty. Oh, and, Netty provides the option to specify a JDK `Provider` in the SslContextBuilder, too, so that _could_ be made configurable as well. 2. Restore the option of specifying a custom SSL context, and prefer this over using the Netty SslContextBuilder in the new ClientX509Util code, when present—this lets users specify a JDK `Provider`, but file based key and trust stores will be required for the native SSL added in 3.9.0. I don't have a strong opinion on which option is better. I can also contribute a code change with either. -- This message was sent by Atlassian Jira (v8.20.10#820010)