[ZOOKEEPER-4828] Minor 3.9 broke custom TLS setup with ssl.context.supplier.class

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Assignee: Unassigned
• Reporter: Jon Marius Venstad
• Created: 22/Apr/24 07:28
• Updated: 22/Apr/24 07:28

Description

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.