Skip to content

Conversation

merks
Copy link
Contributor

@merks merks commented Oct 11, 2024

  • -Djavax.net.ssl.trustStoreType=Windows-ROOT
  • -Djavax.net.ssl.trustStore=NONE

eclipse-platform/eclipse.platform.releng.aggregator#929

- -Djavax.net.ssl.trustStoreType=Windows-ROOT
- -Djavax.net.ssl.trustStore=NONE

eclipse-platform/eclipse.platform.releng.aggregator#929
@merks
Copy link
Contributor Author

merks commented Oct 11, 2024

@jonahgraham @sratz

I think we should go with this...

Copy link
Contributor

@jonahgraham jonahgraham left a 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:

- [ ] 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

## 2024-12

@merks
Copy link
Contributor Author

merks commented Oct 12, 2024

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:

- [ ] 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.

Yes, the SDK product should have these same options and that was overlooked. Good catch.

Is this worthy of a N&N entry in

## 2024-12

Yes, I think we should mention that small but significant change!

@merks merks merged commit 7dbf05d into eclipse-packaging:master Oct 15, 2024
11 checks passed
@merks merks deleted the pr-windows-use-root-certs branch October 15, 2024 17:28
@jonahgraham
Copy link
Contributor

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

@sratz
Copy link
Contributor

sratz commented Oct 29, 2024

I successfully tested M2 with a corporate-internal update site with custom certificate. 👍

@jonahgraham
Copy link
Contributor

Thanks @sratz for testing and reporting back.

@sratz
Copy link
Contributor

sratz commented Jan 31, 2025

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:
https://learn.microsoft.com/en-us/deployedge/microsoft-edge-security-cert-verification
They now always use a combination of roots CAs from the operating system and their own trusted roots.

Sadly, it's not possible to tell the JVM to use a union of multiple trust stores via -Djavax.net.ssl.... parameters.

The proper solution would be to programmatically build an SSLContext with a custom TrustStore as I have suggested back in https://www.eclipse.org/lists//cross-project-issues-dev/msg17927.html.

eclipse-platform/eclipse.platform#680 / eclipse-platform/eclipse.platform#1716 go in the same direction, although way too heavyweight IMHO.

@jonahgraham
Copy link
Contributor

The proper solution would be to programmatically build an SSLContext with a custom TrustStore as I have suggested back in https://www.eclipse.org/lists//cross-project-issues-dev/msg17927.html.

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?

@sratz
Copy link
Contributor

sratz commented Jan 31, 2025

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:

<plugin id="org.apache.aries.spifly.dynamic.bundle" autoStart="true" startLevel="2" />
<plugin id="org.apache.felix.scr" autoStart="true" startLevel="2" />
<plugin id="org.eclipse.core.runtime" autoStart="true" startLevel="4" />
<plugin id="org.eclipse.equinox.common" autoStart="true" startLevel="2" />
<plugin id="org.eclipse.equinox.event" autoStart="true" startLevel="2" />
<plugin id="org.eclipse.equinox.p2.reconciler.dropins" autoStart="true" startLevel="4" />
<plugin id="org.eclipse.equinox.simpleconfigurator" autoStart="true" startLevel="1" />

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants