Question
Eclipse Trust Store Precedence for Conflicting Certificates
Dev Dey
0 reputation · 08 Sept 2021, 05:06 UTC
81.8K views1
Loading…
0 reputation · 08 Sept 2021, 05:06 UTC
Eclipse utilizes the Eclipse Communication Framework (ECF) to handle HTTPS connections for the Marketplace and update sites. Validation logic typically references both the internal secure storage and the JRE cacerts file to establish trust.
In environments using corporate MITM proxies, a scenario may arise where the internal Eclipse secure storage and the system JRE cacerts contain different certificates for the same Common Name (CN). Because ECF may switch between different underlying providers—such as Apache HttpClient and Java URLConnection—the resolution order for these certificates is not explicitly defined in the documentation.
This creates uncertainty when attempting to override a system-level certificate with a specific version stored within the IDE's secure storage.
cacerts?29775 reputation · 08 Sept 2021, 10:49 UTC
There is no global precedence rule for certificate resolution in Eclipse. When identical Common Names (CNs) exist in both the internal secure storage and the JRE cacerts, the trust store that takes precedence is determined by the active Eclipse Communication Framework (ECF) provider used for the request.
The resolution behavior diverges based on the underlying transport implementation:
eclipseSSLContext. It only consults the Eclipse secure storage if the provider is explicitly configured to register the Eclipse trust manager (via the ECF_SSL_TRUST_MANAGER extension point). Otherwise, it may default to the JVM settings.TrustManagerFactory, which reads the cacerts file exclusively. In this path, the internal Eclipse secure storage is ignored entirely.The selection order can vary between these two interfaces because they often instantiate different providers. The Marketplace client (org.eclipse.epp.mpc.ui) historically favors the Apache HttpClient provider, whereas the "Install New Software" dialog (org.eclipse.equinox.p2.ui.sdk) frequently utilizes the URLConnection provider. Consequently, a certificate override in secure storage might work for the Marketplace but fail for p2 updates.
If a provider is configured to check multiple stores and finds certificates with the same CN but different public keys or validity periods, the first matching trust anchor encountered in the provider's trust manager chain wins. There is no logic to select the "most recent" or "most specific" certificate.
To ensure consistent behavior across all ECF providers in corporate MITM environments, the root CA should be added to both the JRE cacerts and the Eclipse secure storage.
To verify which trust manager is being invoked during a connection attempt, launch Eclipse with the following JVM argument:
-Djavax.net.debug=ssl:trustmanagerThe resulting console output will identify the active trust manager implementation and the specific certificate chain being validated.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.