Sebastian,
This issue sounds related to the following Bugzilla, which has kind of
morphed into "update to latest release installs JustJ JRE":
https://bugs.eclipse.org/bugs/show_bug.cgi?id=567504
But in any case, the user noticed because they were expecting their
/etc/ssl/certs/java/cacerts to be used, but the embedded JRE uses its
own cacerts and no others.
I've seen the problem you describe at customer sites as well, where it
caused problems with p2 access to update sites that went through the
corporate firewall so folks had to add root certificates to their JDK
installation.
So this does sound very useful, though I don't understand the full
details and implications...
Regards,
Ed
On 07.10.2020 15:45, Ratz, Sebastian wrote:
Hello,
A JVM brings its own set of root CA certificates as the root of trust
(lib/security/cacerts).
This also means that Eclipse relies on that trust store for every
HTTPS call, e.g. the update mechanism (Eclipse update sites use HTTPS
since not too long, so this was not that big of a problem before).
However – especially in many corporate environments – TLS injection
proxies are deployed that hook into TLS connections and re-sign
traffic using a new certificate.
Usually this certificate is also deployed into the operating system
trust store, such that browser and other functionality is not impacted.
However, since Eclipse relies on the JVM trust store, Eclipse is left
out of the loop here.
This then leads to typical problems such as
sun.security.validator.ValidatorException … PKIX path building failed:
sun.security.provider.SunCertPathBuilderException: unable to find
valid certification path to requested target
In order to work around that issue we have implemented an
javax.net.ssl.SSLContext with custom X509KeyManager and
X509TrustManager that additionally load the operating system trust/key
store (Windows-ROOT and Windows-MY on Windows, and KeychainStore on
macOs). We use this for HTTPS calls that we make from within our own
plugins.
But since we do not modify the JVM-wide default
(javax.net.ssl.SSLContext.setDefault(SSLContext)) in order to avoid
influencing any potential 3^rd -party plugins, we still have to deal
with customer problems where e.g. the update mechanism is affected.
*Is there interest in the platform to have this functionality in the
core platform?*
We could then contribute our implementation and Eclipse Platform could
then use SSLContext.setDefault() to modify the default very early-on
during startup, optionally with a preference to enable/disable this
behavior.
An initial list that would be affected by (would benefit from) this:
* Update mechanism
* EGit
* …
Since the embedded browser has always used the OS trust store, a
discrepancy between that and HTTPS calls made from within Eclipse
would also be resolved.
Best regards,
Sebastian Ratz
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
