9-jdk image has SSL issues

[keeganwitt]

9-b179-jdk image works fine, but the latest 9-jdk image is unable to make SSL connections in Java.

Here's how you can see the issue, create TestHttps.java with

import java.net.URL;
import javax.net.ssl.HttpsURLConnection;

public class TestHttps {
    public static void main(String[] args) {
        try {
            HttpsURLConnection conn = (HttpsURLConnection) new URL(args[0]).openConnection();
            conn.getResponseCode();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

and run

javac TestHttps.java
java -cp . TestHttps "https://www.google.com/"

You'll get

javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
        at java.base/sun.security.ssl.Alerts.getSSLException(Alerts.java:214)
        at java.base/sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1969)
        at java.base/sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1921)
        at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1904)
        at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1436)
        at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413)
        at java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:567)
        at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
        at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1563)
        at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1491)
        at java.base/java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:527)
        at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:320)
        at TestHttps.main(TestHttps.java:10)
Caused by: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
        at java.base/sun.security.validator.PKIXValidator.<init>(PKIXValidator.java:89)
        at java.base/sun.security.validator.Validator.getInstance(Validator.java:181)
        at java.base/sun.security.ssl.X509TrustManagerImpl.getValidator(X509TrustManagerImpl.java:330)
        at java.base/sun.security.ssl.X509TrustManagerImpl.checkTrustedInit(X509TrustManagerImpl.java:180)
        at java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:192)
        at java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:133)
        at java.base/sun.security.ssl.ClientHandshaker.checkServerCerts(ClientHandshaker.java:1825)
        at java.base/sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1655)
        at java.base/sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:260)
        at java.base/sun.security.ssl.Handshaker.processLoop(Handshaker.java:1086)
        at java.base/sun.security.ssl.Handshaker.processRecord(Handshaker.java:1020)
        at java.base/sun.security.ssl.SSLSocketImpl.processInputRecord(SSLSocketImpl.java:1137)
        at java.base/sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1074)
        at java.base/sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
        at java.base/sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1402)
        at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1429)
        ... 8 more
Caused by: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
        at java.base/java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:200)
        at java.base/java.security.cert.PKIXParameters.<init>(PKIXParameters.java:120)
        at java.base/java.security.cert.PKIXBuilderParameters.<init>(PKIXBuilderParameters.java:104)
        at java.base/sun.security.validator.PKIXValidator.<init>(PKIXValidator.java:86)
        ... 23 more

[keeganwitt]

The same test with 9-jre fails with

Exception in thread "main" java.lang.ExceptionInInitializerError
        at java.base/javax.crypto.JceSecurityManager.<clinit>(JceSecurityManager.java:66)
        at java.base/javax.crypto.Cipher.getConfiguredPermission(Cipher.java:2610)
        at java.base/javax.crypto.Cipher.getMaxAllowedKeyLength(Cipher.java:2634)
        at java.base/sun.security.ssl.CipherSuite$BulkCipher.isUnlimited(CipherSuite.java:602)
        at java.base/sun.security.ssl.CipherSuite$BulkCipher.<init>(CipherSuite.java:574)
        at java.base/sun.security.ssl.CipherSuite$BulkCipher.<clinit>(CipherSuite.java:460)
        at java.base/sun.security.ssl.CipherSuite.<clinit>(CipherSuite.java:1074)
        at java.base/sun.security.ssl.SSLContextImpl.getApplicableSupportedCipherSuiteList(SSLContextImpl.java:354)
        at java.base/sun.security.ssl.SSLContextImpl.access$100(SSLContextImpl.java:42)
        at java.base/sun.security.ssl.SSLContextImpl$AbstractTLSContext.<clinit>(SSLContextImpl.java:590)
        at java.base/java.lang.Class.forName0(Native Method)
        at java.base/java.lang.Class.forName(Class.java:292)
        at java.base/java.security.Provider$Service.getImplClass(Provider.java:1844)
        at java.base/java.security.Provider$Service.newInstance(Provider.java:1820)
        at java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:236)
        at java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:164)
        at java.base/javax.net.ssl.SSLContext.getInstance(SSLContext.java:169)
        at java.base/javax.net.ssl.SSLContext.getDefault(SSLContext.java:99)
        at java.base/javax.net.ssl.SSLSocketFactory.getDefault(SSLSocketFactory.java:123)
        at java.base/javax.net.ssl.HttpsURLConnection.getDefaultSSLSocketFactory(HttpsURLConnection.java:335)
        at java.base/javax.net.ssl.HttpsURLConnection.<init>(HttpsURLConnection.java:292)
        at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.<init>(HttpsURLConnectionImpl.java:86)
        at java.base/sun.net.www.protocol.https.Handler.openConnection(Handler.java:62)
        at java.base/sun.net.www.protocol.https.Handler.openConnection(Handler.java:57)
        at java.base/java.net.URL.openConnection(URL.java:1051)
        at TestHttps.main(TestHttps.java:9)
Caused by: java.lang.SecurityException: Can not initialize cryptographic mechanism
        at java.base/javax.crypto.JceSecurity.<clinit>(JceSecurity.java:118)
        ... 26 more
Caused by: java.lang.SecurityException: Can't read cryptographic policy directory: unlimited
        at java.base/javax.crypto.JceSecurity.setupJurisdictionPolicies(JceSecurity.java:324)
        at java.base/javax.crypto.JceSecurity.access$000(JceSecurity.java:73)
        at java.base/javax.crypto.JceSecurity$1.run(JceSecurity.java:109)
        at java.base/javax.crypto.JceSecurity$1.run(JceSecurity.java:106)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at java.base/javax.crypto.JceSecurity.<clinit>(JceSecurity.java:105)
        ... 26 more

[aiannucci]

Faced same issue today with latest image 9-jdk

[yosifkit]

Works fine with jdk-slim or jre-slim, so there is something in the non-headless package that breaks things.

[mjw99]

Seeing this downstream with a Maven project on Bitbucket's pipelines.

[carlossg]

Easy reproducer with maven image in carlossg/docker-maven#50

docker run -it --rm maven:3-jdk-9 mvn dependency:tree

[queer]

Seeing this in the current 9-jre image as well.

[eolivelli]

I got this issue as well
this is a showstopper for upgrading the build pipeline to jdk9
any news ?

[philwebb]

It looks like the cacerts file in JDK 9 release (b181) is empty. It wasn't for the last version I tested (b176). I had to copy the truststore from b176 to make my builds pass again (reaching external https repos).

https://twitter.com/CedricChampeau/status/913679310896156672

[chiralsoftware]

My workaround to this: I have JDK 8 installed. I went in to JDK9_HOME/lib/security and did:

rm cacerts
ln -s /etc/ssl/certs/java/cacerts 

Problem solved. The cacerts file that comes with 181 is empty. After making that fix, Maven works as expected.

[yosifkit]

@chiralsoftware, I apparently don't understand how that fixes it; the file /usr/lib/jvm/java-9-openjdk-amd64/lib/security/cacerts is already a symlink to /etc/ssl/certs/java/cacerts.

$ docker run -it --rm openjdk:9-jdk bash
root@c555aa9be1c4:/# find / -name cacerts
/etc/default/cacerts
/etc/ssl/certs/java/cacerts
/usr/lib/jvm/java-9-openjdk-amd64/lib/security/cacerts
root@c555aa9be1c4:/# ls -l /usr/lib/jvm/java-9-openjdk-amd64/lib/security/cacerts
lrwxrwxrwx 1 root root 27 Aug 24 17:15 /usr/lib/jvm/java-9-openjdk-amd64/lib/security/cacerts -> /etc/ssl/certs/java/cacerts
root@c555aa9be1c4:/# exit

[chiralsoftware]

@yosifkit , I installed from the .tar.gz file

0afa4ff751925e039489b4690667aad746412567ffc71393d6a253001874e592 jdk-9+181_linux-x64_bin.tar.gz

That did not create the link when I untarred it. Creating that link fixed it. I haven't tried the other package files.

[yosifkit]

@chiralsoftware, I understand, this image uses the Debian packaging for openjdk, not the tar-gz file directly (we get many more architectures that way).

[yosifkit]

I did much regression testing using snapshot.debian.org to install openjdk-9-jdk at the same version, 9-b181-4. It works fine from introduction of the -4 version on 24 August 2017 up to and including 6 September 2017 at 00:00:00 UTC and then failed when installed at 7 September 2017 at 00:00:00 UTC. So I've narrowed it down to package updates during the day of 6 September. The list of installed packages that are different between the two images are as follows:

diff /tmp/0906-java.txt /tmp/0907-java.txt
94c94,95
< ii  libegl1-mesa:amd64            17.1.5-1                amd64        free implementation of the EGL API -- runtime
---
> ii  libegl-mesa0:amd64            17.2.0-1                amd64        free implementation of the EGL API -- Mesa vendor library
> ii  libegl1:amd64                 0.2.999+git20170802-3   amd64        Vendor neutral GL dispatch library -- EGL support
105c106
< ii  libgbm1:amd64                 17.1.5-1                amd64        generic buffer management API -- runtime
---
> ii  libgbm1:amd64                 17.2.0-1                amd64        generic buffer management API -- runtime
112,114c113,116
< ii  libgl1-mesa-dri:amd64         17.1.5-1                amd64        free implementation of the OpenGL API -- DRI modules
< ii  libgl1-mesa-glx:amd64         17.1.5-1                amd64        free implementation of the OpenGL API -- GLX runtime
< ii  libglapi-mesa:amd64           17.1.5-1                amd64        free implementation of the GL API -- shared library
---
> ii  libgl1:amd64                  0.2.999+git20170802-3   amd64        Vendor neutral GL dispatch library -- legacy GL support
> ii  libgl1-mesa-dri:amd64         17.2.0-1                amd64        free implementation of the OpenGL API -- DRI modules
> ii  libgl1-mesa-glx               17.2.0-1                amd64        transitional dummy package
> ii  libglapi-mesa:amd64           17.2.0-1                amd64        free implementation of the GL API -- shared library
116a119,121
> ii  libglvnd0:amd64               0.2.999+git20170802-3   amd64        Vendor neutral GL dispatch library
> ii  libglx-mesa0:amd64            17.2.0-1                amd64        free implementation of the OpenGL API -- GLX vendor library
> ii  libglx0:amd64                 0.2.999+git20170802-3   amd64        Vendor neutral GL dispatch library -- GLX support
144c149
< ii  libllvm4.0:amd64              1:4.0.1-3               amd64        Modular compiler and toolchain technologies, runtime library
---
> ii  libllvm5.0:amd64              1:5.0-1                 amd64        Modular compiler and toolchain technologies, runtime library
199c204
< ii  libwayland-egl1-mesa:amd64    17.1.5-1                amd64        implementation of the Wayland EGL platform -- runtime
---
> ii  libwayland-egl1-mesa:amd64    17.2.0-1                amd64        implementation of the Wayland EGL platform -- runtime

I don't really know which of these packages could affect the java ca-certificates file generation. 😕

[fdesu]

The same on my Fedora 26.
I have JDK 9 installed from jdk-9+181_linux-x64_bin.tar.gz as well as @chiralsoftware, the latest stable version built from openjdk hg also has an empty (32 bytes cacerts?) file.

Making a symlink to /etc/pki/java/cacerts fixed a problem in my case, however, could anyone say what this "broken" file is? A broken symlink?

upd: not really helped

[tianon]

@fdesu @chiralsoftware please take discussions of upstream's broken release tarball elsewhere; this issue is discussing a separate issue with the openjdk:9 Docker image which stems from the Debian package it is built from -- the seemingly similar issue with upstream's tarball is not likely to be related, and should be reported to the upstream OpenJDK project instead

[tianon]

Given @yosifkit's diff in #145 (comment), it appears this is somehow related to OpenGL, which is bizarre. That diff (with the timestamps for http://snapshot.debian.org) is probably enough for filing an issue in Debian (https://bugs.debian.org/src:openjdk-9) to see if the Debian Java team can make heads or tails of what's going on here (and why it works with openjdk-9-jdk-headless but not openjdk-9-jdk).

[freakyy85]

having the same problem. would be nice if this could be fixed. thanks. gradlew for example doesnt work making ci builds impossible.

[freakyy85]

or does anyone know a fix for this?

[snakey1980]

@freakyy85 Is it possible for your CI builder to use one of the -slim ones? I switched to 9-jdk-slim to fix my builds.

[freakyy85]

oh yes i can. thanks the slim versions have fixed everything!! :)

[aaron-haskins]

@philwebb, you are right, cacerts keystore is empty in OpenJDK 9. It is a known issue, see here for more details.

[mikaelhg]

@sureshg Are you sure that the bug you quoted is relevant to this case, as the relevant images use Debian's way of populating the cacerts file in any case? If the file is missing when Debian's cacerts generation is called, the JDK9 defaults to creating a pkcs12 format cacerts file, while JDK8 defaulted to the jks format. These two formats are treated differently, and accessing the pkcs12 format cacerts file from java.net SSL code requires explicitly setting the keystore password in -Djavax.net.ssl.trustStorePassword=changeit?

[oflebbe]

One part of the upstream issue is resolved, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894979 .
However simply running apt-get update; apt-get upgrade ; does not work for now. Please run
rm /etc/ssl/certs/java/cacerts ; update-ca-certificates -f
in order to fix the certs, for now. Reported this to upstream

[sohailalam2]

Hello... what's the ETA for resolving this issue?
Its open for over 7 months and none of the workarounds really solves it 😞

I am having the same issue with java 9 in docker FROM openjdk:9-jdk

javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
 at java.base/sun.security.ssl.Alerts.getSSLException(Alerts.java:214) ~[na:na]
 at java.base/sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1969) ~[na:na]
 at java.base/sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1921) ~[na:na]
 at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1904) ~[na:na]
 at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1436) ~[na:na]
 at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413) ~[na:na]
 at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:396) ~[httpclient-4.5.5.jar!/:4.5.5]

[mikaelhg]

Well, it's been resolved in upstream, because rebuilding 9-jdk from what's in the repo currently produces a working cacerts file. We'd only need someone to rebuild and reupload the official docker-library images.

[tianon]

Doing docker pull openjdk:9-jdk followed by docker history --no-trunc --human=false openjdk:9-jdk to check the exact build date of the layer that installs openjdk-9-jdk gives 2018-04-04T12:54:44-07:00, which is just shortly before the upstream fix ("Fri, 13 Apr 2018 14:15:39 +0200").

However, this rebuild will happen following the merge of docker-library/official-images#4281.

[mikaelhg]

Somewhat off topic: the new ubuntu:18.04 images have the same issue, with openjdk-11-jdk installed. All originating from the jks → pkcs12 change in the JDK, and the custom Debian cacerts file generation. However, this means that soon there will be a LOT of people searching for this.

🔥 Ubuntu 1770553: [SRU] backport ca-certificates-java from cosmic (20180413ubuntu1)

🤘 Ubuntu 1769013: Please merge ca-certificates-java 20180413 (main) from Debian unstable (main)

🤘 Ubuntu 1739631: Fresh install with JDK 9 can't use the generated PKCS12 cacerts keystore file

🤘 Debian 894979: ca-certificates-java: does not work with OpenJDK 9, applications fail with InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty

🛠 Debian ca-certificates-java ChangeLog

💥 JDK-8044445 : JEP 229: Create PKCS12 Keystores by Default

💣 JEP 229: Create PKCS12 Keystores by Default

---

Workaround

Used @kurtbrose's pyjks to create a minimal JKS file with the default 'changeit' password.

/usr/bin/printf '\xfe\xed\xfe\xed\x00\x00\x00\x02\x00\x00\x00\x00\xe2\x68\x6e\x45\xfb\x43\xdf\xa4\xd9\x92\xdd\x41\xce\xb6\xb2\x1c\x63\x30\xd7\x92' > /etc/ssl/certs/java/cacerts
/var/lib/dpkg/info/ca-certificates-java.postinst configure

As a gist.

[koppor]

Another workaround with all certificates available (from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894979)

$ sudo apt install openjdk-8-jre
$ sudo rm /etc/ssl/certs/java/cacerts
$ sudo update-ca-certificates --fresh

This works because /etc/ca-certificates/update.d/jks-keystore prefers OpenJDK 8 over OpenJDK 9.

[mikaelhg]

Verified that the image c5eef58c8a2f created at 2018-05-05T11:07:30+03:00 fixes the problem, so this ticket can be closed, @wglambert.

Repro steps:

docker pull openjdk:9-jdk
docker run -it --rm openjdk:9-jdk bash
wget https://github.com/mikaelhg/broken-docker-jdk9-cacerts/raw/master/TestHttps.class
java -cp . TestHttps "https://www.google.com/"

No stack trace == success. (Also verified current 9-jre and 9-jdk-slim, no problems, all worked.)

[tianon]

Awesome, thanks @mikaelhg!

[abelhOrihuela]

This work for me (React Native Stack for Android)

sudo apt install openjdk-8-jre
sudo rm /etc/ssl/certs/java/cacerts
sudo update-ca-certificates --fresh

[Benjapy]

Thanks abelhOrihuela!! it's work now!!!

[JamesYeoman]

I found that by doing an update and upgrade of apt-get, the ca-certs end up being updated and so the SSL issues were fixed

[heroInCommunity]

It seems that openjdk:11.0.1-jre-slim does not work with custom truststores(javax.net.ssl.trustStore) and keystores(javax.net.ssl.keyStore) of pkcs12 format, only with JKS format.
Spent 1 day trying different workarounds. Reverted stores to use JKS.

[mikaelhg]

@heroInCommunity, it sounds like it's a different issue, so your best bet might be to open a new issue and include a reproduction. If you do, please tag me in a comment or something, as I'll need to devise a workaround if the fix is a long time coming.