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)
