[scripts] feat: use CA certificates from Mozilla

[JakubVanek]

Related to ev3dev-lang-java/ev3dev-lang-java#728 (comment)
Inspired by adoptium/adoptium-support#13 (comment)

This removes the use of the CA certificates bundled in the AdoptOpenJDK repository. Instead the CA certificates are generated before each build from the Mozilla's trust database.

This should ensure the most browser-like experience which I'd expect users to expect.

[jabrena]

This change require analysis, I am not saying that the solution is not valid, the point is:

• Why not use cacerts from Java?

[JakubVanek]

Please see adoptium/adoptium-support#13

[JakubVanek]

@jabrena Actually, the cacerts that were used until now were from the Mozilla's list. The debian package ca-certificates-java that was used until recently generates the cacerts file from the system trust store and on Debian this is derived from the Mozilla's one.

[jabrena]

Oki oki, give me the opportunity to read the links, tomorrow, I will approve it.

[jabrena]

Note: Good engineering research :)

[JakubVanek]

@jabrena Actually, the cacerts that were used until now were from the Mozilla's list. The debian package ca-certificates-java that was used until recently generates the cacerts file from the system trust store and on Debian this is derived from the Mozilla's one.

I have realized this is not true actually. The cacerts in JRI come from Mozilla, but the system trust store is currently getting corrupted. The JDK cacerts come from the AdoptOpenJDK/openjdk-build repository (however their builds may not be using it, using the upstream cacerts instead). This PR would move these to up-to-date Mozilla certs. We can also go pure upstream OpenJDK, although it does have its limitations. However in the future that might be the best option if OpenJDK itself decides to inherit from Mozilla's trust store.

[JakubVanek]

Another self-correction: what we refer to as JRI here is actually the Java debian package, while JDK is the tarball that can be downloaded from Jenkins. JRI in tar.gz from Jenkins is self-contained as the JDK is.

[JakubVanek]

Continuing in ev3dev-lang-java/ev3dev-lang-java#731

[jabrena]

Maybe, the certificates could come from OpenSSL:
https://github.com/paketo-buildpacks/libjvm/blob/master/cmd/openssl-certificate-loader/main.go

flagSet.StringVar(&c.CACertificatesPath, "ca-certificates", "", "path to OpenSSL CA Certificates file")

[JakubVanek]

Maybe, the certificates could come from OpenSSL:
https://github.com/paketo-buildpacks/libjvm/blob/master/cmd/openssl-certificate-loader/main.go

flagSet.StringVar(&c.CACertificatesPath, "ca-certificates", "", "path to OpenSSL CA Certificates file")

OpenSSL by itself does not have a trust store (https://stackoverflow.com/a/25169323). However, it does have a container format and I think this is what is the ca-bundle.crt file that is generated by mk-ca-bundle.pl.

[jabrena]

This evening, I will contact you to talk. The three PR are related.

[JakubVanek]

I'd rather want to discuss it here on GitHub. If wanted, I can create a separate issue for the analysis where the discussion would be concentrated so that it is not split between many issues and PRs. I have mostly tried to concentrate new discussion in ev3dev-lang-java/ev3dev-lang-java#731 which is related.

[jabrena]

Oki, we will discuss the alternatives in the issue:
ev3dev-lang-java/ev3dev-lang-java#731

[JakubVanek]

reopening

[jabrena]

Sorry, I am going to close this PR. Open a PR onlye with the changes required for the packaging.
Nothing more.