Hi,
I stumbled onto this issue at the end of last year, and noticed that there has
been no visible activity related to this issue since it was created.
Have there been any internal discussions about the lack of support for the
documented "ssl.context.supplier.class" parameter, or the provided suggested
solutions in the Jira ticket?
I'm available to provide contributions for this fix if needed as well.
/F
________________________________
From: Jon Marius Venstad (Jira) <j...@apache.org>
Sent: Monday, April 22, 2024 09:29
To: dev@zookeeper.apache.org <dev@zookeeper.apache.org>
Subject: [jira] [Created] (ZOOKEEPER-4828) Minor 3.9 broke custom TLS setup
with ssl.context.supplier.class
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)
