On Thu, Oct 15, 2020 at 9:38 AM Ed Merks <ed.me...@gmail.com> wrote: > 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 3rd-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 > > +1 for 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 listcross-project-issues-...@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 >
_______________________________________________ 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
