Temurin-build: Missing cacert from window build (jdk8u172-b11)

[karianna]

_From @nrousseau on June 20, 2018 7:3_

Hello,

Actually the file cacert for the windows build is empty, ie:

jdk8u172-b11/jre/lib/security/cacert

Everything is ok for mac / linux builds, but not windows.

Is it possible to get a new release build with the certificate file?

Thanks

_Copied from original issue: AdoptOpenJDK/openjdk8-releases#11_

[karianna]

_From @DanHeidinga on June 21, 2018 15:15_

FYI @jefrajames - tagging you in this item so you can track the status as we'll close the OpenJ9 issue

[karianna]

_From @donbourne on July 25, 2018 13:7_

I encountered this same issue last week. We were trying to do maven builds, as part of a lab for a conference. Since maven was trying to connect to the maven repo it failed on the SSL handshake since the cacerts weren't present in the JDK. I had to copy the certs from a linux build to get the lab to work... so +1 for fixing this.

[karianna]

_From @planetf1 on July 25, 2018 14:15_

Hit this same problem. Built fine on oracle 172. Switched to openjdk 171, still built fine. Then a few days later a colleague added a new dependency and wham! maven fell over as it couldn't pull an artifact. This is a breakage.

Note that ubuntu 18.04's openjdk build (not adopt) has similar issues - there I ended up copying the cacert file from an oraclejdk... (in both cases format was old style not java 9/10 for the keystore)

[karianna]

_From @sxa555 on July 25, 2018 14:50_

It looks like it was deliberately excluded on Windows under @neomatrix369' commit at https://github.com/AdoptOpenJDK/openjdk-build/commit/685a9370e4735bf479ae5ef301c4691d328a5697 ... I've just attempted a build with it re-enabled and it hasn't aborted at that part so if all goes to plan I'll submit a PR on this.

[karianna]

_From @sxa555 on July 25, 2018 14:50_

Built fine on oracle 172. Switched to openjdk 171, still built fine.

@planetf1 Can you clarify where "openjdk 171" came from that you're having an issue with please? The release builds at adoptopenjdk.net are 8u172 not 8u171.

[karianna]

_From @planetf1 on August 2, 2018 12:52_

I said '71' as I assumed the 71 in the bad version string (another issue open on this) was a truncated 171, but perhaps not.

MacOS

13:52 $ java -version
openjdk version "1.8.0-adoptopenjdk"
OpenJDK Runtime Environment (build 1.8.0-adoptopenjdk-jenkins_2018_05_19_02_01-b00)
OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode)

[karianna]

_From @planetf1 on August 2, 2018 12:55_

It's labelled jdk8u171-b11 when downloaded - yet it's unclear how to resolve that against a command I can run in the installed environment to show what is installed. there should be some match ideally on -version -- but there is when viewing full properties!

In full:
13:54 $ java -XshowSettings:properties
Property settings:
awt.toolkit = sun.lwawt.macosx.LWCToolkit
file.encoding = UTF-8
file.encoding.pkg = sun.io
file.separator = /
gopherProxySet = false
java.awt.graphicsenv = sun.awt.CGraphicsEnvironment
java.awt.printerjob = sun.lwawt.macosx.CPrinterJob
java.class.path = .
java.class.version = 52.0
java.endorsed.dirs = /Users/jonesn/java/jdk8u172-b11/jre/lib/endorsed
java.ext.dirs = /Users/jonesn/Library/Java/Extensions
/Users/jonesn/java/jdk8u172-b11/jre/lib/ext
/Library/Java/Extensions
/Network/Library/Java/Extensions
/System/Library/Java/Extensions
/usr/lib/java
java.home = /Users/jonesn/java/jdk8u172-b11/jre
java.io.tmpdir = /var/folders/fb/mzlmglkd11g00z2wgc4m15nw0000gn/T/
java.library.path = /Users/jonesn/Library/Java/Extensions
/Library/Java/Extensions
/Network/Library/Java/Extensions
/System/Library/Java/Extensions
/usr/lib/java
.
java.runtime.name = OpenJDK Runtime Environment
java.runtime.version = 1.8.0-adoptopenjdk-jenkins_2018_05_19_02_01-b00
java.specification.name = Java Platform API Specification
java.specification.vendor = Oracle Corporation
java.specification.version = 1.8
java.vendor = Oracle Corporation
java.vendor.url = http://java.oracle.com/
java.vendor.url.bug = http://bugreport.sun.com/bugreport/
java.version = 1.8.0-adoptopenjdk
java.vm.info = mixed mode
java.vm.name = OpenJDK 64-Bit Server VM
java.vm.specification.name = Java Virtual Machine Specification
java.vm.specification.vendor = Oracle Corporation
java.vm.specification.version = 1.8
java.vm.vendor = Oracle Corporation
java.vm.version = 25.71-b00
line.separator = \n
os.arch = x86_64
os.name = Mac OS X
os.version = 10.14
path.separator = :
sun.arch.data.model = 64
sun.boot.class.path = /Users/jonesn/java/jdk8u172-b11/jre/lib/resources.jar
/Users/jonesn/java/jdk8u172-b11/jre/lib/rt.jar
/Users/jonesn/java/jdk8u172-b11/jre/lib/sunrsasign.jar
/Users/jonesn/java/jdk8u172-b11/jre/lib/jsse.jar
/Users/jonesn/java/jdk8u172-b11/jre/lib/jce.jar
/Users/jonesn/java/jdk8u172-b11/jre/lib/charsets.jar
/Users/jonesn/java/jdk8u172-b11/jre/lib/jfr.jar
/Users/jonesn/java/jdk8u172-b11/jre/classes
sun.boot.library.path = /Users/jonesn/java/jdk8u172-b11/jre/lib
sun.cpu.endian = little
sun.cpu.isalist =
sun.io.unicode.encoding = UnicodeBig
sun.java.launcher = SUN_STANDARD
sun.jnu.encoding = UTF-8
sun.management.compiler = HotSpot 64-Bit Tiered Compilers
sun.os.patch.level = unknown
user.country = GB
user.dir = /Users/jonesn/Downloads
user.home = /Users/jonesn
user.language = en
user.name = jonesn
user.timezone =

[karianna]

See #469

[DavyLandman]

I might be looking at the wrong builds, but if I'm reading Jenkins correctly this is the windows build that should have this commit in there: https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-windows-x64-hotspot/ And I just downloaded the latest build from there (build 27) and the cacerts file is still empty?

[karianna]

@DavyLandman - What does the java --version string say?

[DavyLandman]

I was going the long way around to get a correct cacerts for my 171 download.

Repo:

$ wget https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-windows-x64-hotspot/27/artifact/workspace/target/OpenJDK8U-jre_x64_windows_hotspot_2018-10-01-03-27.zip
$ 7za l OpenJDK8U-jre_x64_windows_hotspot_2018-10-01-03-27.zip | grep "cacerts"
2018-10-01 05:54:01 .....           32           32  jdk8u181-b13-jre/lib/security/cacerts

So the zip contains a 32byte cacerts file.

I solved my own problem by reading the buildscript and figuring out it just copies it from the repo, so I took that file. Just thought to leave a comment to point out the build server is not producing the right zip yet.

[minhtran83]

@karianna I am still seeing this problem with our Linux builds

build 09-Oct-2018 00:33:15 [INFO] Downloaded from maven-atlassian-com: https://packages.atlassian.com/maven/repository/internal/com/atlassian/pom/base-pom/5.0.18/base-pom-5.0.18.pom (32 kB at 3.6 MB/s)
build 09-Oct-2018 00:33:16 [INFO] BulkDownload: Collected 2 missing build extension GAVs, contacting server...
build 09-Oct-2018 00:33:16 [ERROR] BulkDownload: Error while processing..
build 09-Oct-2018 00:33:16 javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
build 09-Oct-2018 00:33:16 at sun.security.ssl.Alerts.getSSLException (Alerts.java:192)
build 09-Oct-2018 00:33:16 at sun.security.ssl.SSLSocketImpl.fatal (SSLSocketImpl.java:1946)
build 09-Oct-2018 00:33:16 at sun.security.ssl.Handshaker.fatalSE (Handshaker.java:316)
build 09-Oct-2018 00:33:16 at sun.security.ssl.Handshaker.fatalSE (Handshaker.java:310)
build 09-Oct-2018 00:33:16 at sun.security.ssl.ClientHandshaker.serverCertificate (ClientHandshaker.java:1620)
build 09-Oct-2018 00:33:16 at sun.security.ssl.ClientHandshaker.processMessage (ClientHandshaker.java:223)
build 09-Oct-2018 00:33:16 at sun.security.ssl.Handshaker.processLoop (Handshaker.java:1037)
build 09-Oct-2018 00:33:16 at sun.security.ssl.Handshaker.process_record (Handshaker.java:965)
build 09-Oct-2018 00:33:16 at sun.security.ssl.SSLSocketImpl.readRecord (SSLSocketImpl.java:1064)
build 09-Oct-2018 00:33:16 at sun.security.ssl.SSLSocketImpl.performInitialHandshake (SSLSocketImpl.java:1367)
build 09-Oct-2018 00:33:16 at sun.security.ssl.SSLSocketImpl.startHandshake (SSLSocketImpl.java:1395)
build 09-Oct-2018 00:33:16 at sun.security.ssl.SSLSocketImpl.startHandshake (SSLSocketImpl.java:1379)
build 09-Oct-2018 00:33:16 at sun.net.www.protocol.https.HttpsClient.afterConnect (HttpsClient.java:559)

It is pretty the same with this issue https://github.com/oracle/graal/issues/493

Adding this flag will help fix it -Djavax.net.ssl.trustStore=[Path to Adopt OpenJDK 8u181_b13]/jre/lib/security/cacert

But after that it introduces this bug https://github.com/AdoptOpenJDK/openjdk-build/issues/555

09-Oct-2018 05:03:23 org.apache.maven.model.resolution.UnresolvableModelException: Could not transfer artifact com.atlassian.pom:closedsource-pom:pom:5.0.18 from/to maven-atlassian-com (https://packages.atlassian.com/maven/repository/internal): java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
09-Oct-2018 05:03:23 at org.apache.maven.project.ProjectModelResolver.resolveModel (ProjectModelResolver.java:197)
09-Oct-2018 05:03:23 at org.apache.maven.project.ProjectModelResolver.resolveModel (ProjectModelResolver.java:243)
09-Oct-2018 05:03:23 at org.apache.maven.model.building.DefaultModelBuilder.readParentExternally (DefaultModelBuilder.java:1052)
09-Oct-2018 05:03:23 at org.apache.maven.model.building.DefaultModelBuilder.readParent (DefaultModelBuilder.java:830)
09-Oct-2018 05:03:23 at org.apache.maven.model.building.DefaultModelBuilder.build (DefaultModelBuilder.java:332)
09-Oct-2018 05:03:23 at org.apache.maven.project.DefaultProjectBuilder.build (DefaultProjectBuilder.java:432)
09-Oct-2018 05:03:23 at org.apache.maven.project.DefaultProjectBuilder.build (DefaultProjectBuilder.java:400)
09-Oct-2018 05:03:23 at org.apache.maven.project.DefaultProjectBuilder.build (DefaultProjectBuilder.java:363)
09-Oct-2018 05:03:23 at org.apache.maven.graph.DefaultGraphBuilder.collectProjects (DefaultGraphBuilder.java:414)
09-Oct-2018 05:03:23 at org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor (DefaultGraphBuilder.java:405)
09-Oct-2018 05:03:23 at org.apache.maven.graph.DefaultGraphBuilder.build (DefaultGraphBuilder.java:82)
09-Oct-2018 05:03:23 at org.apache.maven.DefaultMaven.buildGraph (DefaultMaven.java:507)
09-Oct-2018 05:03:23 at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:219)
09-Oct-2018 05:03:23 at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
09-Oct-2018 05:03:23 at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
09-Oct-2018 05:03:23 at org.apache.maven.cli.MavenCli.execute (MavenCli.java:954)
09-Oct-2018 05:03:23 at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
09-Oct-2018 05:03:23 at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
09-Oct-2018 05:03:23 at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
09-Oct-2018 05:03:23 at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
09-Oct-2018 05:03:23 at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
09-Oct-2018 05:03:23 at java.lang.reflect.Method.invoke (Method.java:498)
09-Oct-2018 05:03:23 at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)
09-Oct-2018 05:03:23 at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
09-Oct-2018 05:03:23 at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)
09-Oct-2018 05:03:23 at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
09-Oct-2018 05:03:23 Caused by: org.eclipse.aether.resolution.ArtifactResolutionException: Could not transfer artifact com.atlassian.pom:closedsource-pom:pom:5.0.18 from/to maven-atlassian-com (https://packages.atlassian.com/maven/repository/internal): java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty

I am running with the latest nightly build OpenJDK8U_x64_linux_hotspot_2018-09-30-17-14.tar.gz

[DavyLandman]

@karianna and @johnoliver I think this issue can be closed, both windows and linux builds contain the same cacerts now.

@minhtran83 if downloading the latest releases from CI haven't fixed your issue, maybe you should open a new issue, and provide some more context in that issue.

Windows

$ wget https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-windows-x64-hotspot/lastSuccessfulBuild/artifact/workspace/target/OpenJDK8U-jdk_x64_windows_hotspot_2018-10-11-03-27.zip
$ 7za l OpenJDK8U-jdk_x64_windows_hotspot_2018-10-11-03-27.zip | grep "cacerts"
2018-10-11 05:53:59 .....        88998        59348  jdk8u181-b13/jre/lib/security/cacerts

Linux

$ curl -L https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-linux-x64-hotspot/lastSuccessfulBuild/artifact/workspace/target/OpenJDK8U-jdk_x64_linux_hotspot_2018-10-11-03-52.tar.gz 2> /dev/null | tar ztv | grep "cacerts"
-rw-rw-r-- jenkins/jenkins   88998 2018-10-11 06:02 ./jdk8u181-b13/jre/lib/security/cacerts

[minhtran83]

Thanks a lot @DavyLandman

[ColinHebert]

@karianna @DavyLandman, should we expect a new release of AdoptOpenJDK8 with those certificates? Or are we expecting to download/run nightlies?

[ColinHebert]

@karianna @DavyLandman, should we expect a new release of AdoptOpenJDK8 with those certificates? Or are we expecting to download/run nightlies?

[ColinHebert]

@karianna @DavyLandman, should we expect a new release of AdoptOpenJDK8 with those certificates? Or are we expecting to download/run nightlies?

[ColinHebert]

@karianna @DavyLandman, should we expect a new release of AdoptOpenJDK8 with those certificates? Or are we expecting to download/run nightlies?

[karianna]

@ColinHebert New release will be coming out u192

[pppq]

Can confirm that the u192 HotSpot download archive for Windows, https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u192-b12/OpenJDK8U-jdk_x64_windows_hotspot_8u192b12.zip contains a ~100 KB cacerts file in jre/lib/security, and I don't get a "do you accept this certificate" confirmation dialog in Java-based desktop applications.