openjdk: 'the trustAnchors parameter must be non-empty' error 11-jdk
Affected image tags: 11-jdk-slim
, 11-jdk
Issue
Ran across this while attempting to package a spring-boot application using the Maven wrapper (mvnw package
). This results in the following stacktrace when trying to retrieve the parent POM:
Exception in thread "main" javax.net.ssl.SSLException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:129)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:321)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:259)
at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1314)
at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:408)
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:1581)
at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1509)
at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:245)
at org.apache.maven.wrapper.DefaultDownloader.downloadInternal(DefaultDownloader.java:73)
at org.apache.maven.wrapper.DefaultDownloader.download(DefaultDownloader.java:60)
at org.apache.maven.wrapper.Installer.createDist(Installer.java:64)
at org.apache.maven.wrapper.WrapperExecutor.execute(WrapperExecutor.java:121)
at org.apache.maven.wrapper.MavenWrapperMain.main(MavenWrapperMain.java:55)
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:308)
at java.base/sun.security.ssl.X509TrustManagerImpl.checkTrustedInit(X509TrustManagerImpl.java:176)
at java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:188)
at java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:129)
at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:626)
at java.base/sun.security.ssl.CertificateStatus$CertificateStatusConsumer.consume(CertificateStatus.java:292)
at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444)
at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:421)
at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:178)
at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
... 10 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)
... 25 more
Looks like an issue with the CA certificate store, similar to #145. Could also be related to the changes introduced in #259.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 45
- Comments: 31 (8 by maintainers)
Commits related to this issue
- Update 11 images to use stretch-backports; yay stable Also drop old ca-certificates-java fix — committed to docker-library/openjdk by yosifkit 6 years ago
This commit I think to blame: https://github.com/docker-library/openjdk/commit/c3023e4da10d10e9c9775eabe2d7baac146e7ae1#diff-c338262eaf0fd203322a06702be174e0
Funny the commit saying “stable”:
when can we expect a fix to hit dockerhub?
This breaks downstream usage of gradle, dependency fetching doesn’t work.
Another workaround is to move back to the sid-tagged image (
openjdk:11-slim-sid
, for example, confirmed working for me)Looks to also be basically identical to https://bugs.debian.org/894979
The “stable” word in that commit message is referring to Debian Stretch (which is currently “Debian Stable”). The older images were based on “Debian Unstable”, which is definitely not a great base for images.
We do have some tests, but none of them cover usage of CA certificates so this one slipped. Sorry for the trouble.
If we can come up with a very simple way to reproduce the issue with minimal code, I’d love to add a new integration test to help us prevent this in the future.
Should be building as soon as https://github.com/docker-library/official-images/pull/5237 merges.
I’ve managed to reproduce with something as simple as
new URL("https://google.com").openStream();
. 👍@carlossg it is
docker pull maven@sha256:eaf3e683397276d4a1b198ed0c14d8e4ee4732ce8117dc120f55491ebc570f4f
You can see the history of changes from https://github.com/docker-library/repo-info/tree/master/repos
Then see what you want, if maven then: https://github.com/docker-library/repo-info/tree/master/repos/maven
Then “remote” https://github.com/docker-library/repo-info/tree/master/repos/maven/remote
Then see what the exact tag you want + “.md”: https://github.com/docker-library/repo-info/blob/master/repos/maven/remote/3.6.0-jdk-11.md
Then check the history of changes: https://github.com/docker-library/repo-info/commit/71d8089b6f13f135a675aacc8790191f51f1b0ae#diff-cf0598a44c7a5812abe472e73c1f96b5
I hope thats helps.
http://bit.ly/2Ar73Lp
Alright, new test is merged in https://github.com/docker-library/official-images/pull/5232, workaround is open at https://github.com/docker-library/openjdk/pull/263.
Wow I was about to open the same ticket, yes I confirm that and wasted 4 hours trying to figure out the issue, I did get the previous version using this: https://github.com/docker-library/repo-info/commits/master/repos/openjdk/remote/11.md so I used the latest change from 21 days ago: https://github.com/docker-library/repo-info/commit/88142bab02ec82880d21201eadbfc9ff37e7c88f#diff-ddaaa92a4237756eb9f1b9dd7af15fc7
And that worked, the latest version got some critical changes seems and pushed without proper testing, I have 2 images:
Using the latest is not working:
The error:
But using old hash from 21 days ago worked for me: