Eclipse SSL trust management: no UI mechanism for temporary host trust exceptions

Short answer

Eclipse has no per-host trust exception UI because nothing in its networking stack owns certificate trust. ECF, p2, m2e, and EGit/JGit all delegate TLS validation to the JVM's default SSLContext (JSSE), which consults the process-wide trust store — typically $JAVA_HOME/lib/security/cacerts or whatever javax.net.ssl.trustStore points at. A PKIX path building error is the JRE talking, not Eclipse, and Eclipse has no preference page, no trust store, and no callback hook that intercepts that failure. Implementing per-project or per-repository trust requires new platform code, not configuration.

What the delegation model actually implies

Because the SSLContext is process-wide, every consumer — p2 update fetches, m2e repository access, JGit operations — shares one trust decision. That explains two things in your scenario:

• Corporate MITM proxies: the re-signing internal CA must be in the JVM's trust store. There is no Eclipse-level workaround short of changing which trust store the JVM loads at launch.
• m2e masking failures: m2e caches Maven metadata under the local repository; a stale cache can hide intermittent TLS failures until a forced refresh (mvn -U or "Update Project"). That is Maven caching behavior, not an Eclipse SSL feature.

What per-project trust would require

There is no supported preference for this today. The realistic architectural path is an ECF-level contribution:

1. Register a custom SSLContextFactory via ECF's filetransfer SSL extension (see org.eclipse.ecf.provider.filetransfer.httpclient4 for the existing hook).
2. Wrap the default TrustManager: on validation failure, check a project- or host-scoped certificate store persisted in IEclipsePreferences (instance scope).
3. For a UI exception model, prompt through a non-blocking UI job on first failure, persist accepted certificates, and re-initialize the SSLContext.
4. Delegate to the default context for non-matching hosts so internal Eclipse traffic is unaffected.

Two hard caveats: replacing the SSLContext dynamically is not thread-safe against already-open connections, and a custom ECF factory does not cover EGit — JGit uses the JVM context independently and would need its own configuration.

Isolating trust in distribution packages

Without code changes, the only working mechanism is launch-time, not UI-time:

• Ship a custom cacerts and launch with -Djavax.net.ssl.trustStore=... in eclipse.ini — still a VM argument, but packaged, not manual.
• Bundle a JRE with the distribution and point the launcher at it, keeping trust fully separate from the host JRE.
• Unlocking a per-installation store via Equinox secure storage is possible but fragile in headless CI containers that lack an OS keyring.

Verify before you build

Run Eclipse with -Djavax.net.debug=ssl:trustmanager and trigger a p2 update to confirm exactly which trust store is consulted. Note that Eclipse 2024-09+ requires Java 21, whose JSSE disabled-algorithm defaults differ from Java 11/17 — validate any prototype against the JRE you actually ship.