Skip to content
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

Missing cacert from window build (jdk8u172-b11) #478

Closed
karianna opened this issue Sep 10, 2018 · 20 comments
Closed

Missing cacert from window build (jdk8u172-b11) #478

karianna opened this issue Sep 10, 2018 · 20 comments
Assignees
Labels
bug Issues that are problems in the code as reported by the community good first issue Issues that have been deemed "easy" and excellent for new contributors help wanted Issues that need an extra hand helping out with them
Milestone

Comments

@karianna
Copy link
Contributor

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 karianna added bug Issues that are problems in the code as reported by the community good first issue Issues that have been deemed "easy" and excellent for new contributors help wanted Issues that need an extra hand helping out with them labels Sep 10, 2018
@karianna
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

From @sxa555 on July 25, 2018 14:50

It looks like it was deliberately excluded on Windows under @neomatrix369' commit at 685a937 ... 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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

See #469

@DavyLandman
Copy link

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
Copy link
Contributor Author

karianna commented Oct 1, 2018

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

@DavyLandman
Copy link

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.

@karianna karianna reopened this Oct 1, 2018
@karianna karianna assigned johnoliver and unassigned karianna Oct 1, 2018
MarkEWaite added a commit to MarkEWaite/docker-lfs that referenced this issue Oct 7, 2018
OpenJDK 8 171 does not deliver a cacerts file. It can't download over
https due to that build error.

See adoptium/temurin-build#478
@minhtran83
Copy link

minhtran83 commented Oct 9, 2018

@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 oracle/graal#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 #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
Copy link

@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
Copy link

Thanks a lot @DavyLandman

@ColinHebert
Copy link

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

3 similar comments
@ColinHebert
Copy link

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

@ColinHebert
Copy link

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

@ColinHebert
Copy link

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

@karianna
Copy link
Contributor Author

@ColinHebert New release will be coming out u192

@pppq
Copy link

pppq commented Dec 23, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issues that are problems in the code as reported by the community good first issue Issues that have been deemed "easy" and excellent for new contributors help wanted Issues that need an extra hand helping out with them
Projects
None yet
Development

No branches or pull requests

6 participants