I have installed the latest binary openjdk version. When I try to run a java application that connects to websites (like google.com) using https the connection fails because of an invalid signature. I cannot confirm this invalid signature if I run the application with java from icedtea-bin-3.16. If I try to run the application on one of my private websites where the certificate is issued by Letsencrypt it works. So it's not failing for all https connections. Reproducible: Always Steps to Reproduce: 1. emerge "=dev-java/openjdk-bin-11.0.7_p10-r1" 2. wget https://confluence.atlassian.com/download/attachments/117455/SSLPoke.java # see https://matthewdavis111.com/java/poke-ssl-test-java-certs/ 3. javac SSLPoke.java 4. java SSLPoke google.com Actual Results: javax.net.ssl.SSLHandshakeException: Invalid ECDH ServerKeyExchange signature at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131) at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:313) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:269) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:260) at java.base/sun.security.ssl.ECDHServerKeyExchange$ECDHServerKeyExchangeMessage.<init>(ECDHServerKeyExchange.java:325) at java.base/sun.security.ssl.ECDHServerKeyExchange$ECDHServerKeyExchangeConsumer.consume(ECDHServerKeyExchange.java:531) at java.base/sun.security.ssl.ServerKeyExchange$ServerKeyExchangeConsumer.consume(ServerKeyExchange.java:111) 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:422) at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:183) at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1144) at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1055) at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:395) at java.base/sun.security.ssl.SSLSocketImpl.ensureNegotiated(SSLSocketImpl.java:709) at java.base/sun.security.ssl.SSLSocketImpl$AppOutputStream.write(SSLSocketImpl.java:962) at java.base/sun.security.ssl.SSLSocketImpl$AppOutputStream.write(SSLSocketImpl.java:934) at SSLPoke.main(SSLPoke.java:23) Expected Results: Successfully connected. The same application works with Ubuntu and openjdk-11 installed. I was able to reproduce the issue also with Java 11 and Java 14 downloaded manually from adoptopenjdk.net on my Gentoo installation. I have not really an idea how to debug this.
Created attachment 644186 [details] emerge --info
When I add the elliptic curve algorithms to the list of disabled algos it works: jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, \ EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH, ECDHE, ECDSA in conf/security/java.security
are you sure that java binary you run is actually openjdk-bin-11? try using full path to be sure. also make sure that JAVA_HOME JDK_HOME variables are not set to something strange. and if you enable gentoo-vm useflag, make sure openjdk-11 is selected. for a while we've been using cental keystore location and removing bundled certs that come with adoptopenjdk. you can try running > update-ca-certificates it should refresh system/user certs and re-generate java cacerts stored at /etc/ssl/certs/java/cacerts of if you do not want to refresh all system certs, you just run just update java ones. > trust extract --overwrite --format=java-cacerts --filter=ca-anchors --purpose server-auth /etc/ssl/certs/java/cacerts (this snippet is located in /etc/ca-certificates/update.d/java-cacerts ) it may have gotten stale. works for me in default configuration: /opt/openjdk-bin-11/bin/java SSLPoke google.com 443 Successfully connected in theory manually downloaded jdk from adoptopenjdk should use whatever comes bundled with it in lib/security JAVA_HOME should not influence it, but maybe something changed.
> are you sure that java binary you run is actually openjdk-bin-11? try using > full path to be sure. I used the packge installed from portage and a manually downloaded version from adoptopenjdk. > also make sure that JAVA_HOME JDK_HOME variables are not set to something > strange. With the manually downloaded version I used the full path to the executable (with JAVA_HOME set and unset). > and if you enable gentoo-vm useflag, make sure openjdk-11 is selected. I tried the package from installed from portage with gentoo-vm enabled (and enabled with eselect) and disabled. > for a while we've been using cental keystore location and removing bundled > certs that come with adoptopenjdk. > you can try running > > > update-ca-certificates For the version installed from the portage tree I tried this. For the manually downloaded version I didn't modify the included cert list. Thanks for your hints but as described in my other comment it looks to me that it's related to an issue with elliptic curve algorithms. I haven't changed/updated the cacerts. I have only added the algorithms to the list of the disabled and then it's working.
openjdk-bin-11.0.7_p10-r1 is gone. does the problem persist with more recent versions like openjdk-bin-11.0.24_p8 or with openjdk-bin:{17,21}?
