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

9-jdk image has SSL issues #145

Closed
keeganwitt opened this Issue Sep 11, 2017 · 45 comments

Comments

Projects
None yet
@keeganwitt
Copy link

keeganwitt commented Sep 11, 2017

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

This comment has been minimized.

Copy link
Author

keeganwitt commented Sep 11, 2017

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

This comment has been minimized.

Copy link

aiannucci commented Sep 11, 2017

Faced same issue today with latest image 9-jdk

@yosifkit

This comment has been minimized.

Copy link
Member

yosifkit commented Sep 12, 2017

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

@mjw99

This comment has been minimized.

Copy link

mjw99 commented Sep 13, 2017

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

@carlossg

This comment has been minimized.

Copy link

carlossg commented Sep 21, 2017

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

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

This comment has been minimized.

Copy link

queer commented Sep 25, 2017

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

@eolivelli

This comment has been minimized.

Copy link

eolivelli commented Oct 2, 2017

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

@philwebb

This comment has been minimized.

Copy link

philwebb commented Oct 3, 2017

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

This comment has been minimized.

Copy link

chiralsoftware commented Oct 5, 2017

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

This comment has been minimized.

Copy link
Member

yosifkit commented Oct 5, 2017

@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

This comment has been minimized.

Copy link

chiralsoftware commented Oct 5, 2017

@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

This comment has been minimized.

Copy link
Member

yosifkit commented Oct 5, 2017

@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

This comment has been minimized.

Copy link
Member

yosifkit commented Oct 5, 2017

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

This comment has been minimized.

Copy link

fdesu commented Oct 6, 2017

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

This comment has been minimized.

Copy link
Member

tianon commented Oct 6, 2017

@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

hrytsenko-sigma pushed a commit to hrytsenko-sigma/ping that referenced this issue Oct 8, 2017

Anton Hrytsenko
Use the fine-grained Docker image.
Use Oracle JDK instead of OpenJDK because of the SSL issue that impacts Maven (docker-library/openjdk#145).

donald-w added a commit to donald-w/sample-java9-modules-maven that referenced this issue Oct 9, 2017

@tianon

This comment has been minimized.

Copy link
Member

tianon commented Oct 12, 2017

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

This comment has been minimized.

Copy link

freakyy85 commented Oct 14, 2017

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

@freakyy85

This comment has been minimized.

Copy link

freakyy85 commented Oct 15, 2017

or does anyone know a fix for this?

@snakey1980

This comment has been minimized.

Copy link

snakey1980 commented Oct 15, 2017

@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

This comment has been minimized.

Copy link

freakyy85 commented Oct 15, 2017

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

@aaron-haskins

This comment has been minimized.

Copy link

aaron-haskins commented Oct 19, 2017

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

notnoopci added a commit to circleci/circleci-images that referenced this issue Dec 4, 2017

Use JDK 9-slim cacerts for OpenJDK 9
OpenJDK 9 images have empty cacert files which was reported in
docker-library/openjdk#145 and http://bugs.java.com/view_bug.do?bug_id=8189357 .

Here we use a cacert cache from `openjdk:9-slim` image that seems to be
populated correctly.
@mikaelhg

This comment has been minimized.

Copy link

mikaelhg commented Feb 14, 2018

@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

This comment has been minimized.

Copy link

oflebbe commented Apr 15, 2018

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

norrs added a commit to norrs/secor that referenced this issue Apr 20, 2018

Fixes missing cacerts bug currently happening in openjdk:8 image
This patch can be reverted once Debian Stable (Stretch) has backported the fix
mentioned in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894979 .
See docker-library/openjdk#145 (comment)
@sohailalam2

This comment has been minimized.

Copy link

sohailalam2 commented Apr 25, 2018

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

This comment has been minimized.

Copy link

mikaelhg commented Apr 25, 2018

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

This comment has been minimized.

Copy link
Member

tianon commented Apr 25, 2018

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

This comment has been minimized.

Copy link

mikaelhg commented Apr 28, 2018

Somewhat off topic: the new ubuntu:18.04 images have the same issue, with openjdk-11-jdk installed. All originating from the jkspkcs12 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

This comment has been minimized.

Copy link

koppor commented May 2, 2018

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

This comment has been minimized.

Copy link

mikaelhg commented May 10, 2018

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

This comment has been minimized.

Copy link
Member

tianon commented May 10, 2018

Awesome, thanks @mikaelhg!

@tianon tianon closed this May 10, 2018

@wglambert wglambert reopened this May 10, 2018

@wglambert wglambert closed this May 10, 2018

@abelhOrihuela

This comment has been minimized.

Copy link

abelhOrihuela commented Jun 6, 2018

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

This comment has been minimized.

Copy link

Benjapy commented Jul 8, 2018

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

gusenov added a commit to gusenov/examples-java that referenced this issue Jul 31, 2018

@JamesYeoman

This comment has been minimized.

Copy link

JamesYeoman commented Aug 30, 2018

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

This comment has been minimized.

Copy link

heroInCommunity commented Dec 5, 2018

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

This comment has been minimized.

Copy link

mikaelhg commented Dec 5, 2018

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment