Hi David, Many thanks for bringing this up, this is indeed a valid point that Istio service-mesh can manage TLS and in this case the application does not have to care about it. However as far as I understand Istio cannot be used without a Kubernetes cluster and if we don't have Kubernetes (e.g. use VM-s or bare metal servers) this is not an option for us. So probably it is beneficial to have a solution for this case as well.
Best Regards, Dávid David Smiley <[email protected]> ezt írta (időpont: 2026. aug. 19., Sze, 15:08): > Are any of you working in an organization that has embraced > managed-mesh/Istio [1]? It's a game changer for the better; I have seen > the future with that. It pushes mTLS down to an infrastructure concern; > the TCP/IP services above communicate in cleartext unaware of the lower > level encryption. No service needs to care about TLS, let alone mTLS, let > alone FIPS. It removed a considerable burden across all the services in > the organization, including complexity / quirky matters on a service by > service basis. Only the team managing the Istio infrastructure needed to > know how that stuff worked. More importantly, it significantly raised the > security posture across the board. > > [1] https://istio.io/latest/about/service-mesh/ > > On Wed, Aug 19, 2026 at 4:36 AM Dávid Paksy <[email protected]> wrote: > > > Hi, > > > > I now changed the implementation of option #1 to use separate SSLContext > > instances in SSLContextAndOptions for client and server role. Each > > SSLContext is initialized with standard PKIX managers from its own > keystore > > / truststore. There is no custom key- or trust-manager. As far as I > > understand, this should work in FIPS mode. > > There is no change in config properties, and it is fully backward > > compatible. > > > > What are your thoughts? > > > > Thanks, > > Dávid > > > > Dávid Paksy <[email protected]> ezt írta (időpont: 2026. aug. 17., H, > > 11:31): > > > > > Hi Andor, > > > > > > Sorry, I was too quick to send my response. Probably you didn't meant > the > > > FIPS mode property in ZooKeeper but FIPS mode in Java. > > > > > > Enabling FIPS mode in Java imposes strict constraints on which > KeyManager > > > and TrustManager implementations can be instantiated and initialized. > > > I looked into this and in FIPS mode, SSLContext.init() will throw an > > > exception if custom manager instances are passed. Something like: > > > java.security.KeyManagementException: FIPS mode: only SunJSSE > > > TrustManagers may be used. > > > > > > I agree that this can be an issue for the custom KeyManager and > > > TrustManager implementation as both custom classes get passed directly > to > > > SSLContext.init(). So this approach will not work in FIPS mode. > > > > > > I'll look into this more and come up with another proposal. > > > > > > Best Regards, > > > Dávid > > > > > > > > > Dávid Paksy <[email protected]> ezt írta (időpont: 2026. aug. 17., H, > > > 10:20): > > > > > >> Hi Andor, > > >> > > >> Many thanks for your feedback. > > >> > > >> Hmm, very good question. As far as I understand, in FIPS mode, the > > >> split-truststore routing should still function. > > >> > > >> The certificate routing in ClientServerX509TrustManager is still > active > > >> in FIPS mode. > > >> > > >> This class "sits above" the FIPS branching. It routes: > > >> - checkServerTrusted -> client trust manager (validates remote server > > >> certs) > > >> - checkClientTrusted -> server trust manager (validates remote client > > >> certs) > > >> > > >> Each inner trust manager is whatever createTrustManager() returns - in > > >> FIPS mode that's the raw JDK PKIX trust manager instead of > > ZKTrustManager. > > >> The routing itself is unaffected. > > >> > > >> Regarding EKU enforcement, there's no explicit EKU checking in > > >> ZKTrustManager or ClientServerX509TrustManager.The JDK's built-in PKIX > > >> validator enforces EKU constraints. So in FIPS mode, EKU validation > > should > > >> work identically. > > >> > > >> Or do you think I'm missing something? > > >> > > >> Best Regards, > > >> Dávid > > >> > > >> Andor Molnár <[email protected]> ezt írta (időpont: 2026. aug. 13., > Cs, > > >> 23:00): > > >> > > >>> Hi David, > > >>> > > >>> Option #1 > > >>> > > >>> You mentioned a custom ZooKeeper trustmanager implementation which > > picks > > >>> the right certificate for client/server validation. How would it work > > in > > >>> FIPS mode when we don’t use custom trustmanagers, but rely on JDK > > >>> implementation? > > >>> > > >>> Apart from this I tend to support this option. Sounds more secure and > > it > > >>> could include a fallback mechanism to Option #2 if only one keystore > is > > >>> specified in the config. > > >>> > > >>> Andor > > >>> > > >>> > > >>> > > >>> > On Aug 12, 2026, at 10:44, Dávid Paksy <[email protected]> wrote: > > >>> > > > >>> > Hi All, > > >>> > > > >>> > I’d like to start a discussion to improve public Certificate > > >>> Authorities > > >>> > (CA) compatibility. Industry standards and public CA-s (like > > DigiCert) > > >>> are > > >>> > sunsetting multi-use certificates, making the current requirement > for > > >>> dual > > >>> > serverAuth and clientAuth Extended Key Usages (EKUs) difficult to > > >>> manage. > > >>> > > > >>> > ZooKeeper currently only supports dual-purpose certificates (or no > > EKU > > >>> > extension at all which means unconstrained). These certificates > carry > > >>> both > > >>> > the serverAuth and clientAuth EKUs, meaning the same key and > > >>> certificate is > > >>> > used whether the service running on the host is acting as a TLS > > server > > >>> or > > >>> > as a client in a mutual-TLS (mTLS) handshake. > > >>> > In a ZooKeeper quorum cluster, every node acts as both TLS client > and > > >>> > server to its peers, making the single-EKU question especially > > >>> relevant for > > >>> > inter-node communication. > > >>> > > > >>> > In order to support single EKU certs I see the following two > possible > > >>> > options. > > >>> > > > >>> > 1. **Separate keystore / truststore files for client and server TLS > > >>> roles** > > >>> > > > >>> > This requires new config properties (under "ssl." and "ssl.quorum." > > >>> > prefixes): > > >>> > - client.keyStore.{location,password,passwordPath,type} > > >>> > - server.trustStore.{location,password,passwordPath,type} > > >>> > > > >>> > For code changes we could introduce new X509ExtendedKeyManager and > > >>> > X509ExtendedTrustManager implementations: > > >>> > - ClientServerX509KeyManager - routes chooseServerAlias() to the > > >>> server > > >>> > keystore and chooseClientAlias() to a dedicated client keystore > > >>> > - ClientServerX509TrustManager - routes checkClientTrusted() > > >>> (validating > > >>> > incoming client certs when acting as server) to a dedicated > > server-role > > >>> > truststore, and checkServerTrusted() (validating remote server > certs > > >>> when > > >>> > acting as client) to the default truststore > > >>> > > > >>> > If the new properties are absent, we fall back to the existing > shared > > >>> > keystore / truststore (to be fully backward compatible). > > >>> > > > >>> > This approach would give independent trust chains and better > > >>> > least-privilege in hardened environments - file permissions can > > >>> restrict > > >>> > which process/role accesses which key, however this means more > files > > >>> per > > >>> > node and more config properties to set. > > >>> > > > >>> > I filed ZOOKEEPER-5070 for this and have a draft PR there. > > >>> > > > >>> > --- > > >>> > > > >>> > 2. **Single keystore with different alias for the client and server > > >>> roles** > > >>> > > > >>> > We use the PKIX KeyManagerFactory which performs EKU-aware alias > > >>> selection. > > >>> > Here we might not need code change. But this way we are relying on > > JDK > > >>> > implementation behavior that isn't formally specified in the > > >>> > KeyManagerFactory API contract; may differ across JDK vendors (IBM > > >>> Semeru, > > >>> > Azul, GraalVM). > > >>> > > > >>> > However Trust side has no equivalent auto-routing — the > TrustManager > > >>> uses > > >>> > one truststore for both checkClientTrusted() and > > checkServerTrusted(). > > >>> We > > >>> > cannot use different CAs for client-facing vs quorum communication. > > >>> > > > >>> > This approach would mean fewer files, simpler deployment but > > principle > > >>> of > > >>> > least privilege is weaker - a compromised process always has both > > keys. > > >>> > > > >>> > --- > > >>> > > > >>> > This single EKU topic is also being discussed on the Apache Kafka > > >>> developer > > >>> > mailing list and they tend to favor option #2 (Single keystore with > > >>> > different aliases): > > >>> > https://lists.apache.org/[email protected]:lte=1M:eku > > >>> > > > >>> > > > >>> > What are your thoughts on these? > > >>> > Any experience using single EKU certificates with ZooKeeper? > > >>> > Do you see more possible options? > > >>> > > > >>> > Best Regards, > > >>> > Dávid > > >>> > > >>> > > >
