[
https://issues.apache.org/jira/browse/ZOOKEEPER-4828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dávid Paksy reassigned ZOOKEEPER-4828:
--------------------------------------
Assignee: Dávid Paksy
> 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
> Assignee: Dávid Paksy
> Priority: Major
>
> 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)
