Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Platform: Enable usage of operating system root certificates / trust store in default SSLContext?


On Thu, Oct 15, 2020 at 9:38 AM Ed Merks <ed.merks@xxxxxxxxx> 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 list
cross-project-issues-dev@xxxxxxxxxxx
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@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Back to the top