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 * ... 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
