-
Notifications
You must be signed in to change notification settings - Fork 16
Specify VM options on Windows to use the system certificate store. #224
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Specify VM options on Windows to use the system certificate store. #224
Conversation
- -Djavax.net.ssl.trustStoreType=Windows-ROOT - -Djavax.net.ssl.trustStore=NONE eclipse-platform/eclipse.platform.releng.aggregator#929
I think we should go with this... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I approve this, although ideally it should be added to platform/sdk in the same release. This PR also saves me the work in this release step:
Line 43 in 3392fc7
- [ ] Synchronize any changes to [platform.product](https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/master/eclipse.platform.releng.tychoeclipsebuilder/eclipse.platform.repository/platform.product) into all the `epp.product` files. |
Is this worthy of a N&N entry in
Line 8 in 3392fc7
## 2024-12 |
Yes, the SDK product should have these same options and that was overlooked. Good catch.
Yes, I think we should mention that small but significant change! |
The 2024-12 M2 EPP build that contains the new system certificate store options is now available for testing. If you have access to a system that should be helped by this change, please let me know if these new packages work. See announcement in https://www.eclipse.org/lists/epp-dev/msg06939.html |
I successfully tested M2 with a corporate-internal update site with custom certificate. 👍 |
Thanks @sratz for testing and reporting back. |
So a few months have passed and while this certainly improved the situation in many corporate environments, it appears in others this has made it worse: There appear to be environments in which the trusted third-party root CA list is heavily stripped down, e.g. are missing Let's Encrypt. In those environments the reverse is now necessary and the .ini parameters need to be manually removed. Looks like browsers are also dealing with the same and have changed their approch: Sadly, it's not possible to tell the JVM to use a union of multiple trust stores via The proper solution would be to programmatically build an eclipse-platform/eclipse.platform#680 / eclipse-platform/eclipse.platform#1716 go in the same direction, although way too heavyweight IMHO. |
It sounds like this needs to happen before Eclipse app starts to ensure the correct context is in place before any early accesses are done, i.e. in Equinox somewhere early on. Does Equinox/felix/OSGI have anything like this? |
I suppose we'd need to do this during startup of one of the bundles with the lowest startup level: packages/packages/org.eclipse.epp.package.java.product/epp.product Lines 70 to 76 in e66c4e9
|
eclipse-platform/eclipse.platform.releng.aggregator#929