Sandor Molnar created KNOX-3263:
-----------------------------------
Summary: CM service discovery issue in FIPS clusters
Key: KNOX-3263
URL: https://issues.apache.org/jira/browse/KNOX-3263
Project: Apache Knox
Issue Type: Bug
Affects Versions: 3.0.0
Reporter: Sandor Molnar
Assignee: Sandor Molnar
Fix For: 3.0.0
Attachments: image-2026-02-26-09-27-27-015.png
In FIPS-enabled clusters with JDK17 (on RH9), Knox cannot connect to CM during
initial service discovery (nor during the periodical config analysis events),
because CM's ApiClient is trying to load the JVM's default truststore (via
'{{{}new OkHttpClient(){}}}' in line 59, see below) before we reach to the
point where we can set the properly configured SSL truststore. The reason is:
the default truststore's password is missing.
Knox configures the truststore properly later, but the {{DiscoveryApiClient}}
is a child class of that -> we implicitly call the default constructor of CM's
{{{}ApiClient{}}}, that looks like this (as of today):
!image-2026-02-26-09-27-27-015.png|height=400!
I tried to reach out to the CM team and asked them to provide a new version of
this class where Knox could provide the '{{{}httpClient{}}}' as a constructor
argument, but I hit the wall multiple times, they insisted on putting the
`'{{{}-Djavax.net.ssl.trustStorePassword{}}}' System property as a JVM
argument, which could result in a security leak in certain environments (please
note this is FIPS, with end-users apply the highest security standards).
This leaves us no other option but to bypass this and set the above System
property in a way such that:
* it's not exposed in plain text on a simple '{{{}ps aux{}}}'
* it's only set for a very short time window, when we actually need it (when
we initiate Knox's own DiscoveryApiClient)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
