Bug 567504 - Use system trust store on Windows instead of cacerts

[sratz]

Use the Windows operating system trust store instead of the cacerts bundled with the JVM.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=567504

[merks]

Do we generally expect that the Windows trust store will be more up-to-date? I.e., is there a possibility that a recently published Termurin-based JRE would have root certificates not in the Windows trust store?

[sratz]

Do we generally expect that the Windows trust store will be more up-to-date? I.e., is there a possibility that a recently published Termurin-based JRE would have root certificates not in the Windows trust store?

That's certainly a possibility but unlikely that this should cause any trouble. Microsoft regularly updates the trusted roots:
https://learn.microsoft.com/en-us/security/trusted-root/release-notes

I guess it comes down to what expectations of users we want to fulfill. The operating system trust store is the one users are used to (e.g. in browsers) and what they probably expect to be used in arbitrary 3rd party applications. It may also contains corporate specific certificates.

Our experience is that it is quite unintuitive that the EPP packages come with their own cacerts ('Why does it work in my browser but not in Eclipse?')

[merks]

This issue of certificates used by a corporate firewall is quite a common problem and with an embedded JRE this is even harder for users to fix, especially for the installer where the whole thing is packaged as a *.exe...

[merks]

@sratz

Note that I tried these options in the installer, but the result just hangs trying to access the internet. I have not had time to track down what might be causing that. Maybe the installer is special because it extracts itself into the temp folder. Using the options with a debug launch works fine...

[sratz]

@sratz

Note that I tried these options in the installer, but the result just hangs trying to access the internet. I have not had time to track down what might be causing that. Maybe the installer is special because it extracts itself into the temp folder. Using the options with a debug launch works fine...

I went trough the JDK sources and apparently the correct properties to set actually are

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

instead of

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

Can you see if using NONE helps in the Installer?

[merks]

Yes, the installer works with this in the product:

      <vmArgsWin>-Djavax.net.ssl.trustStoreType=Windows-ROOT
-Djavax.net.ssl.trustStore=NONE
      </vmArgsWin>

[akurtakov]

Is there anything still planned here?

[merks]

I've not changed this for the installer because I'm kind of scared to do that because this isn't something I can really test...

[akurtakov]

So should this one be closed if nothing will be done?

[merks]

I do get the feeling this is a correct and good thing. I’ve seen more than once this solves problems inside firewalls.

[BeckerWdf]

@sratz: Should we merge this?

[sratz]

@sratz: Should we merge this?

I updated the PR to use the correct NONE instead of NUL.

Technically this works, but

• This is only the platform product. The impact would probably be bigger if that was done in the EPPs' INI files.
• This only improves the situation on Windows.

[akurtakov]

@niraj-modi Would you please review this one as it's Windows specific?

[akurtakov]

What is the status here?

[merks]

I've been experimenting with this today and hence I can definitely confirm that it really works. Previously I was able to access some sites only by adding the certificates to the Java installation's cacerts. But today updated some JDKs today then of course my workarounds stopped working. So this time I installed the certificates using crtmgr which helps make firefox happy and making the installer happy only after using these two options The installed IDE (Eclipse SDK) works well with these options too.

There was mention of this also being easy to do on macos, I believe by using -Djavax.net.ssl.trustStoreType=KeychainStore:

https://stackoverflow.com/questions/14280578/how-to-set-up-java-vm-to-use-the-root-certificates-truststore-handled-by-mac-o

I think we should do the Windows this for EPP as well. And it would be great if someone knew if this worked well on macos too...

[merks]

I can confirm that the IDE functions better with these options than it does without.

[merks]

/request-license-review

[github-actions]

/request-license-review

License review requests:

• p2/orbit/p2.eclipse.plugin/org.apache.lucene.analysis-common/9.12.0.v20240929-0900

After all reviews have concluded, re-run the license-vetting check from the Github Actions web-interface to update its status.

Workflow run (with attached summary files):
https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/actions/runs/11292041017

[sratz]

There was mention of this also being easy to do on macos, I believe by using -Djavax.net.ssl.trustStoreType=KeychainStore:

https://stackoverflow.com/questions/14280578/how-to-set-up-java-vm-to-use-the-root-certificates-truststore-handled-by-mac-o

I think we should do the Windows this for EPP as well. And it would be great if someone knew if this worked well on macos too...

This looks promising! We will do some more extensive tests on macOS next week and update the PR.

And I agree, this should go into all products (platform + EPP) in a coordinated manner.

[merks]

FYI, I spent an embarrassing amount of time tracking down why these options made the Tycho-built installers fail. It was simply because the module jdk.crypto.mscapi was not part of the minimal JustJ JRE which is now fixed:

eclipse-justj/justj@2d6c63d

Because this module is specific to Windows, it's very well hidden in scheme of things, so I thought worth mentioning here.

[sratz]

So the situation on macOS is more complicated.

The correct system properties would be

-Djavax.net.ssl.trustStoreProvider=Apple 
-Djavax.net.ssl.trustStoreType=KeychainStore
-Djavax.net.ssl.trustStore=NONE

however this does NOT have the desired effect:

macOS distinguishes between a 'System' keystore and a 'System Roots' keystore:

The 'System' keystore contains those corporate certificates that we are interested in, but all the other commonly/publicly trusted CAs are in the 'System Roots' store.

With the system properties above, we would only get access to the 'System' store and this would essentially break all existing standard scenarios, so is not an option.

What we would need is a union of both keystores, which is currently not possible (neither is accessing the 'System Roots' nor is telling the JVM to use a union of multiple stores).

[merks]

The union is something that the JDK would need to support. It seems odd that it's so poorly support...

In any case, do you plan to amend this PR to update sdk.product? M2 is rapidly approaching...

[sratz]

The union is something that the JDK would need to support. It seems odd that it's so poorly support...

A union can be achieved in code via a custom SSLContext: javax.net.ssl.SSLContext.init(KeyManager[], TrustManager[], SecureRandom).

We are using this already for our product-specific HTTPS calls, but as for setting this as the default system-wide SSLContext we could be too late in the game unless done at a very early stage after JVM startup.

It would be better if the JVM provided more flexible configuration so this is not needed.

In any case, do you plan to amend this PR to update sdk.product? M2 is rapidly approaching...

Done.

[sratz]

/request-license-review

[github-actions]

/request-license-review

License review requests:

• p2/orbit/p2.eclipse.plugin/org.apache.lucene.analysis-common/9.12.0.v20240929-0900

After all reviews have concluded, re-run the license-vetting check from the Github Actions web-interface to update its status.

Workflow run (with attached summary files):
https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/actions/runs/11329998432

[merks]

Ignore the license thing. I'm so frustrated with that problem. 😱

eclipse-orbit/orbit-simrel#43
https://gitlab.eclipse.org/eclipsefdn/emo-team/iplab/-/issues/16675

[scottslewis]

The union is something that the JDK would need to support. It seems odd that it's so poorly support...

A union can be achieved in code via a custom SSLContext: javax.net.ssl.SSLContext.init(KeyManager[], TrustManager[], SecureRandom).

If there are still two ECF filetransfer providers included with Eclipse (apache httpclient 5 and java jre httpclient), and the fact that this issue remains unaddresssed as per

https://gitlab.eclipse.org/eclipse-wg/ide-wg/ide-wg-dev-funded-efforts/ide-wg-dev-funded-program-planning-council-top-issues/-/issues/37

Currently, these two providers handle SSLContext creation/init usage differently and so will respond differently to any additional/earlier customization of SSLContext (e.g. calling SSLContext.init in some other place in Eclipse).

We are using this already for our product-specific HTTPS calls, but as for setting this as the default system-wide SSLContext we could be too late in the game unless done at a very early stage after JVM startup.

Right. With all previous filetransfer providers SSLContext customization has been done for Eclipse install/update in the org.eclipse.ecf.ssl fragment. The java jre httpclient currently does not.

[JavaJoeS]

My attempts to add some PKI into eclipse-platform did not seem to be well received. I was directed to try to utilize marketplace for a launching platform for PKI. I did just that. However, in my travels I have found a lot of different implementations of SSLContext throughout the eclipse package. Most of these implementations trounce on any SSLContext.getDefault() that may have been set up to a certain specification, i.e, SSLContext,init(keyMgr, trustMgr, securerandom) with valid parameters.

[merks]

@sratz

I assume this PR is ready to merge.

I believe this comment is @jonahgraham's approval:

eclipse-packaging/packages#224 (review)

[jonahgraham]

Thanks for making the change to sdk.product too. +1