Environment:
- ClickHouse Java client / JDBC driver version: 0.6.3 (and 0.8.5)
- Java version: 21
- Connection Pool / Framework: HikariCP / Spring
Use case
We store enterprise database certificates and private keys in an encrypted database storage. At runtime, our application programmatically fetches, decrypts these materials, and builds a custom Java javax.net.ssl.SSLContext entirely in memory (RAM). Due to strict security policies, we are strictly prohibited from writing these certificates to the disk, even as temporary files.
The native ClickHouseClient (v2 API) natively supports complex objects via options:
.setOption(ClickHouseClientOption.SSL_CONTEXT, myInMemorySslContext)
The Problem
However, when integrating ClickHouse into an enterprise stack using connection pools (like HikariCP), we are forced to operate through the standard JDBC java.sql.DriverManager interface using java.util.Properties.
If we attempt to pass the live SSLContext object using the generic inheritance of Properties.put():
properties.put("ssl_context", myInMemorySslContext);
The JDBC driver immediately crashes during the configuration parsing stage before making any network calls:
java.lang.IllegalArgumentException: Property key and value should be a string
at com.clickhouse.jdbc.internal.JdbcConfiguration.initProperties(JdbcConfiguration.java:192)
The driver's JdbcConfiguration strictly enforces that every property value must be an instanceof String, effectively breaking the leaky abstraction of the underlying HTTP client which is fully capable of accepting a raw Java object.
Why existing solutions fail our use-case
-
custom_socket_factory (0.8.x): It accepts a String class name, but provides no way to pass a connection/server context argument (unlike PostgreSQL's sslfactoryarg or MS SQL's trustManagerConstructorArg). In a multi-tenant environment with HikariCP background threads, a no-args factory cannot dynamically know which specific server's certificate to pull from our memory registry.
-
Global State Mutation: Mutating the global JVM state via SSLContext.setDefault() is unacceptable for an application connecting to multiple distinct secured servers.
Proposed Solution
Please relax the strict instanceof String validation in JdbcConfiguration.initProperties() specifically for complex object options like
ClickHouseClientOption.SSL_CONTEXT.
Allowing the JDBC wrapper to safely pass the live SSLContext object down to the underlying HTTP client builder would gracefully solve diskless dynamic TLS configuration for all Java Enterprise setups.
Environment:
Use case
We store enterprise database certificates and private keys in an encrypted database storage. At runtime, our application programmatically fetches, decrypts these materials, and builds a custom Java javax.net.ssl.SSLContext entirely in memory (RAM). Due to strict security policies, we are strictly prohibited from writing these certificates to the disk, even as temporary files.
The native ClickHouseClient (v2 API) natively supports complex objects via options:
.setOption(ClickHouseClientOption.SSL_CONTEXT, myInMemorySslContext)
The Problem
However, when integrating ClickHouse into an enterprise stack using connection pools (like HikariCP), we are forced to operate through the standard JDBC java.sql.DriverManager interface using java.util.Properties.
If we attempt to pass the live SSLContext object using the generic inheritance of Properties.put():
The JDBC driver immediately crashes during the configuration parsing stage before making any network calls:
The driver's JdbcConfiguration strictly enforces that every property value must be an instanceof String, effectively breaking the leaky abstraction of the underlying HTTP client which is fully capable of accepting a raw Java object.
Why existing solutions fail our use-case
custom_socket_factory (0.8.x): It accepts a String class name, but provides no way to pass a connection/server context argument (unlike PostgreSQL's sslfactoryarg or MS SQL's trustManagerConstructorArg). In a multi-tenant environment with HikariCP background threads, a no-args factory cannot dynamically know which specific server's certificate to pull from our memory registry.
Global State Mutation: Mutating the global JVM state via SSLContext.setDefault() is unacceptable for an application connecting to multiple distinct secured servers.
Proposed Solution
Please relax the strict instanceof String validation in JdbcConfiguration.initProperties() specifically for complex object options like
Allowing the JDBC wrapper to safely pass the live SSLContext object down to the underlying HTTP client builder would gracefully solve diskless dynamic TLS configuration for all Java Enterprise setups.