Missing CA certificates in jdk8u181-b13

[detouched]

The jdk8u181-b13 update lost roughly half of cacerts entries: it has only 80 entries while jdk8u172-b11 has 157.

This causes SSL errors like this (tried with some domains of Google and Amazon):

Caught: 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
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
    at script_from_command_line.run(script_from_command_line:1)
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
    ... 1 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
    ... 1 more

I tried Docker images as well as downloadable tar.gz – they both have the same version of truncated cacerts file.

[sxa]

Which platform were you seeing this on @detouched?

[detouched]

Pretty much all for "OpenJDK 8 with Hotspot" option, just double checked these all:

OpenJDK8U-jdk_x64_mac_hotspot_8u181b13.tar.gz
OpenJDK8U-jdk_ppc64_aix_hotspot_8u181b13.tar.gz
OpenJDK8U-jdk_x64_linux_hotspot_8u181b13.tar.gz
OpenJDK8U-jdk_x64_windows_hotspot_8u181b13.zip
OpenJDK8U-jdk_s390x_linux_hotspot_8u181b13.tar.gz

I also tried following Docker images where I initially faced this issue:

adoptopenjdk/openjdk8:alpine-slim
adoptopenjdk/openjdk8:jdk8u181-b13

I then compared cacerts to the one shipped in adoptopenjdk/openjdk8:jdk8u172-b11, which works fine, and found that the newer one is truncated.

[Ganeshgautam]

I am getting following exception as well and have found out that its an issue with the certs coming in the jdk build. 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

I am attaching an image below showing the number of certificates in Adopt jdk8u172-b11, jdk8u181-b13 and Oracle jdk 1.8.0_172 respectively for the Mac distribution.

[matt404]

My team is attempting to move to AdoptOpenJDK and just encountered a related error. The issue was encountered running on MacOS. This looks like a major bug.

[ERROR] Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:3.3.0.603:sonar (default-cli) on project esom-load-bgservice: Unable to execute SonarQube: Fail to get bootstrap index from server: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

[Ganeshgautam]

After some digging, I have found that the certificate which is popular and missing in jdk8u181-b13 is "Starfield Services Root Certificate Authority" root cert, now acquired by Amazon. Oracle JDK 8 and jdk8u172-b11 bundles this certificate in cacert. Various amazon trust root CAs are listed here: https://www.amazontrust.com/repository/

It has also been added to Oracle Open JDK 11 recently. See this: https://bugs.openjdk.java.net/browse/JDK-8198891

[Ganeshgautam]

As a workaround People can install the cert from Amazon Trust Repository. Following command might help with verifying whether a "Starfield Services Root Certificate Authority" cert is present or not: echo 'changeit'|keytool -list -v -keystore $(find ${JAVA_HOME} -name cacerts) -name cacerts)|grep 'Owner'|grep 'Star'

And use the below command to install the above cert in cacert: wget https://www.amazontrust.com/repository/SFSRootCAG2.pem && keytool -import -trustcacerts -keystore $JAVA_HOME/jre/lib/security/cacerts -storepass changeit -alias Root -import -file SFSRootCAG2.pem && rm SFSRootCAG2.pem

[karianna]

@johnoliver - Interesting, looks like we may need to backport certs from latest 11

[davidmankin]

Now that PR #688 is merged, what's the release flow look like? When/How does it end up in Docker images or release tar.gz?

[karianna]

The nightly builds should now produce a version with the new cacerts. The next release 8u192 should also pick up these changes (hopefully next week)

[nitinsurana]

The latest available for Ubuntu14.04 is still 8u171-b11-2~14.04, which doesn't have the certs - https://launchpad.net/~openjdk-r/+archive/ubuntu/ppa Is there a plan to release an update ?

Unfortunately, the command provided by @Ganeshgautam doesn't work, probably just minor syntax errors.

[karianna]

@nitinsurana YThe version available by launchpad is not by AdoptOpenJDK, you'll have to manually download from our site.

[tofi86]

@karianna wrote:

@johnoliver - Interesting, looks like we may need to backport certs from latest 11

I ran into this very same issue today on Mac OS but for AdoptOpenJDK 11 build 11.0.5+10 (HotSpot VM) and was astonished when I read this thread and your comment that the issue should have been fixed for jdk8 by backporting certs from jdk11. Indeed, my tests with AdoptOpenJDK 8 were successfull. But JDK 11 throws an Exception:

I tried a HttpURLConnection HEAD request to https://www.google.com which failed in AdoptOpenJDK 11.0.5+10 with this exception but works very well in AdoptOpenJDK 8.

javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
    at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
    at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:320)
    at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:263)
    at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:258)
    at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:641)
    at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.onCertificate(CertificateMessage.java:460)
    at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume(CertificateMessage.java:360)
    at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
    at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443)
    at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:421)
    at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:177)
    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)
    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:1587)
    at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1515)
    at java.base/java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:527)
    at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:334)
    at de.paginagmbh.common.internet.NetTest.URLTester(NetTest.java:82)
    at de.paginagmbh.common.internet.NetTest.testInternetConnection(NetTest.java:48)
    at de.paginagmbh.epubchecker.UpdateCheck.<init>(UpdateCheck.java:95)
    at de.paginagmbh.epubchecker.MainGUI$9.doInBackground(MainGUI.java:839)
    at de.paginagmbh.epubchecker.MainGUI$9.doInBackground(MainGUI.java:1)
    at java.desktop/javax.swing.SwingWorker$1.call(SwingWorker.java:304)
    at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
    at java.desktop/javax.swing.SwingWorker.run(SwingWorker.java:343)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
    at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
    at java.base/sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:385)
    at java.base/sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:290)
    at java.base/sun.security.validator.Validator.validate(Validator.java:264)
    at java.base/sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:313)
    at java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:222)
    at java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:129)
    at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:625)
    ... 27 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
    at java.base/sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
    at java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
    at java.base/java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297)
    at java.base/sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:380)
    ... 33 more

Do you have any clue why this still happens for JDK 11?

[johnoliver]

@tofi86 I dont have a Mac to test, but www.google.com is working for me with 11.0.5+10 on linux, and using the same cacert store.

If you can recreate the issue, can you give us the output of:

openssl s_client -connect www.google.com:443

On that machine.

[tofi86]

If you can recreate the issue, can you give us the output of:

openssl s_client -connect www.google.com:443

Sure thing:

openssl s_client -connect www.google.com:443
CONNECTED(00000005)
depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
verify return:1
depth=1 C = US, O = Google Trust Services, CN = GTS CA 1O1
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN = www.google.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=www.google.com
   i:/C=US/O=Google Trust Services/CN=GTS CA 1O1
 1 s:/C=US/O=Google Trust Services/CN=GTS CA 1O1
   i:/OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFiTCCBHGgAwIBAgIQMtfVXJQ+SlsIAAAAAB8R3TANBgkqhkiG9w0BAQsFADBC
MQswCQYDVQQGEwJVUzEeMBwGA1UEChMVR29vZ2xlIFRydXN0IFNlcnZpY2VzMRMw
EQYDVQQDEwpHVFMgQ0EgMU8xMB4XDTE5MTExMzA5MDkxM1oXDTIwMDIwNTA5MDkx
M1owaDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcT
DU1vdW50YWluIFZpZXcxEzARBgNVBAoTCkdvb2dsZSBMTEMxFzAVBgNVBAMTDnd3
dy5nb29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2RjV
l+qoCQyzLWAAov9f+tX8NnopxNGvI0ZM5f2nxWDEXp2aGUPFfOwmbzU1z3GgtlhN
sxYy1/v7/z/TQfs2jp0Ih8/VbJPwcvd/MIUydjXJN98A7f+V+g21NWGhsxx/ke/0
vwu8NXkBTUj1xdBKS9XEegM9VSBz5fRc6R4c+fp4R60OhiAFO+N4KySU3ZcYjwnZ
SYj1guENKsXQ0hAGfE6q4Do7a5IlyhtrNPQJDtWrrXd0M3tOJrPVRPW90zxZXoLD
zeL48HEz4ZOeaLYF7JRC3kWpQM0QrfEdHgsAzf32i4YSJW0+QKCP1LrW2CPGCs1s
xcwucv62mSdGfoeLZQIDAQABo4ICUzCCAk8wDgYDVR0PAQH/BAQDAgWgMBMGA1Ud
JQQMMAoGCCsGAQUFBwMBMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFE5cH7tOZt2M
EoIrsBjGm2PW9vwcMB8GA1UdIwQYMBaAFJjR+G4Q68+b7GCfGJAboOt9Cf0rMGQG
CCsGAQUFBwEBBFgwVjAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AucGtpLmdvb2cv
Z3RzMW8xMCsGCCsGAQUFBzAChh9odHRwOi8vcGtpLmdvb2cvZ3NyMi9HVFMxTzEu
Y3J0MBkGA1UdEQQSMBCCDnd3dy5nb29nbGUuY29tMCEGA1UdIAQaMBgwCAYGZ4EM
AQICMAwGCisGAQQB1nkCBQMwLwYDVR0fBCgwJjAkoCKgIIYeaHR0cDovL2NybC5w
a2kuZ29vZy9HVFMxTzEuY3JsMIIBAwYKKwYBBAHWeQIEAgSB9ASB8QDvAHYAsh4F
zIuizYogTodm+Su5iiUgZ2va+nDnsklTLe+LkF4AAAFuZD0QwwAABAMARzBFAiB/
1Vyg9oc5HyhTrum94PGFx02Qz9MpmE+w1SDPQYrS9AIhAK2V0Lgq/USGG7jpRQaL
ra4/QVyQufCypokbJRMY0Y/2AHUAXqdz+d9WwOe1Nkh90EngMnqRmgyEoRIShBh1
loFxRVgAAAFuZD0QqAAABAMARjBEAiB6XIdvV73VfsyAT2/+BF0nl5b88nV+CwkW
mIC59W9QVwIgdeqPPFsEhSFWXkbMHTUTsGZn+v6gvNOYRj06WyTsbEYwDQYJKoZI
hvcNAQELBQADggEBAFb6bdyuZVGFZie2WZErJdEmhojTXQ3L2pZ3T+jj7urMGVip
gG/zxmtPtjITQJhRwNlmTeoLgKClnI9AFIbV8WXivDyjnSW1GY+z4b3MP4aH32BO
mOwvRqf/jHSU/vo5FCBxz1LqD7HRL2cXKwQLbt1jPD+rpoXI83vE7bi77OLDitm2
kyF5s9SXka+mavAEi8/hNv1VUWYpfPalw8jnaS8iTD2t0nG7mhuA0Te67H+Q7eMz
DREKSCXYHBwateTQ8v5u6UDYpa2+ilpPEHdixllTFWPo001YVtjvSXUAug9Me5TR
ABhmx8uKbpbUitZ0S5hcWsZnFpyt8prr5b0gczc=
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google LLC/CN=www.google.com
issuer=/C=US/O=Google Trust Services/CN=GTS CA 1O1
---
No client certificate CA names sent
Server Temp Key: ECDH, X25519, 253 bits
---
SSL handshake has read 3190 bytes and written 285 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-CHACHA20-POLY1305
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-CHACHA20-POLY1305
    Session-ID: F0DE351C6CCB5AB747833C03AE2FA2F80E8E1313C6821D3AC4257A819B6E7BFA
    Session-ID-ctx:
    Master-Key: 96AD9065E90F91625884DC18883F9494E4DBC6C2D661A89C677F4CD7ED54FD1CDA7886FB0782BED363A8BC57EE065E98
    TLS session ticket lifetime hint: 100800 (seconds)
    TLS session ticket:
    0000 - 00 df 86 45 35 63 fe a3-01 99 b8 05 60 3e 09 5d   ...E5c......`>.]
    0010 - 4d 2e a1 c2 e3 12 0a 3a-f5 fa 14 a4 43 14 7b bd   M......:....C.{.
    0020 - a5 11 53 1a 65 9a 88 4b-19 70 4f 7c dc fc bf 48   ..S.e..K.pO|...H
    0030 - 01 18 05 56 ff a6 06 4e-58 86 a4 5f c2 3c 66 d6   ...V...NX.._.<f.
    0040 - 18 a4 2d 31 62 05 3c 97-30 16 b3 b2 92 25 b1 0e   ..-1b.<.0....%..
    0050 - 67 f3 c5 35 3f 20 3e 2b-59 ca f3 80 01 d2 45 d7   g..5? >+Y.....E.
    0060 - d8 9c 39 ed 52 a3 02 ab-1c 74 cb bd 20 3f 7b b7   ..9.R....t.. ?{.
    0070 - 40 5c 69 93 20 0e 76 97-01 f0 c4 b2 60 b1 81 bb   @\i. .v.....`...
    0080 - ab 1a 51 32 8d 33 66 e7-88 ea b9 72 59 03 e5 5e   ..Q2.3f....rY..^
    0090 - 1f 39 0f b8 3f ac 8b 9c-cf 2c 2d 26 2e 73 bc 1e   .9..?....,-&.s..
    00a0 - 5a 1e d1 cb 56 2a 8d d7-b3 4e c6 b6 38 fd fa 91   Z...V*...N..8...
    00b0 - 01 1e 31 be fb 80 aa 7b-41 7a f3 f0 77 dd 44 7f   ..1....{Az..w.D.
    00c0 - 55 bf 9f ea 26 09 0c 4d-e4 22 39 f9 fd 98 41 f7   U...&..M."9...A.
    00d0 - 3a eb 33 16 cd                                    :.3..

    Start Time: 1576586896
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---
read:errno=0

[tofi86]

Then in the next step I tried to reproduce with an SSCCE:

import java.io.IOException;
import java.net.HttpURLConnection;
import java.net.MalformedURLException;
import java.net.URL;

public class UrlConnectionTest {

    public static void main(String[] args) throws MalformedURLException {
        URL url = new URL("https://www.google.com");

        try {
            HttpURLConnection urlConnect = (HttpURLConnection) url.openConnection();
            urlConnect.setReadTimeout(10000);
            urlConnect.setRequestMethod("HEAD");
            System.out.println(urlConnect.getResponseCode());
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

While it failed in my program code at urlConnect.getResponseCode() with an IOException, it works fine in the SSCCE.

While digging deeper, it turned out a colleague once set this at program start:

// Workaround for SSL connection errors in Java 7 ( https://stackoverflow.com/questions/7615645/ )
System.setProperty("jsse.enableSNIExtension", "false");

in order to avoid javax.net.ssl.SSLProtocolException: handshake alert when connecting to certain SSL sites with Oracle Java 7(+).

If I add this before the try in the SSCCE it fails for AdoptOpenJDK 11 and 13, but works in AdoptOpenJDK 8.

I tried removing the setProperty(...) from my Application and it works at the moment for Oracle Java 1.7 and 1.8 and also for AdoptOpenJDK 8, 11, 13. So I'll most certainly remove this setting and bump the version requirement to Java 8 – just to be sure.

However, can you explain why the SSCCE with jsse.enableSNIExtension = false fails in AOJDK 11 but works in 8?

[karianna]

@johnoliver not urgent but re-opening this as there seems to be an open question on this. Feel free to shift to the support repo if we deem it to be an isolated case.

[tlk]

Hi there! I believe I am seeing something similar.

This is from a Raspberry Pi with OpenJDK11:

$ uname -a
Linux pi.local 4.19.93-v7l+ #1290 SMP Fri Jan 10 16:45:11 GMT 2020 armv7l GNU/Linux

$ lsb_release -d
Description:    Raspbian GNU/Linux 10 (buster)

# Using javac from openjdk-11-jdk-headless (Raspbian) to compile a test program
$ wget -q https://gist.githubusercontent.com/4ndrej/4547029/raw/84d3bff7bba262b3f77baa32a43873ea95993e45/SSLPoke.java
$ /usr/bin/javac -version
javac 11.0.6
$ /usr/bin/javac SSLPoke.java
$ java SSLPoke downloads.arduino.cc 443
Successfully connected
$ java SSLPoke www.cloudflare.com 443
Successfully connected
$

# Now let's download and test AdoptOpenJDK
$ wget -q wget https://github.com/AdoptOpenJDK/openjdk11-binaries/releases/download/jdk-11.0.6%2B10/OpenJDK11U-jdk_arm_linux_hotspot_11.0.6_10.tar.gz
$ tar xzf OpenJDK11U-jdk_arm_linux_hotspot_11.0.6_10.tar.gz

$ ./jdk-11.0.6+10/bin/java SSLPoke downloads.arduino.cc 443
javax.net.ssl.SSLHandshakeException: PKIX path validation failed: java.security.cert.CertPathValidatorException: signature check failed
    at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
    at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:320)
    at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:263)
    at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:258)
    at java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkServerCerts(CertificateMessage.java:1332)
    at java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.onConsumeCertificate(CertificateMessage.java:1207)
    at java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.consume(CertificateMessage.java:1150)
    at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
    at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443)
    at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:421)
    at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:177)
    at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
    at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1151)
    at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1062)
    at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
    at java.base/sun.security.ssl.SSLSocketImpl.ensureNegotiated(SSLSocketImpl.java:716)
    at java.base/sun.security.ssl.SSLSocketImpl$AppOutputStream.write(SSLSocketImpl.java:969)
    at java.base/sun.security.ssl.SSLSocketImpl$AppOutputStream.write(SSLSocketImpl.java:941)
    at SSLPoke.main(SSLPoke.java:28)
Caused by: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: signature check failed
    at java.base/sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:369)
    at java.base/sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:263)
    at java.base/sun.security.validator.Validator.validate(Validator.java:264)
    at java.base/sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:313)
    at java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:222)
    at java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:129)
    at java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkServerCerts(CertificateMessage.java:1316)
    ... 14 more
Caused by: java.security.cert.CertPathValidatorException: signature check failed
    at java.base/sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:135)
    at java.base/sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:237)
    at java.base/sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:145)
    at java.base/sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:84)
    at java.base/java.security.cert.CertPathValidator.validate(CertPathValidator.java:309)
    at java.base/sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:364)
    ... 20 more
Caused by: java.security.SignatureException: Signature does not match.
    at java.base/sun.security.x509.X509CertImpl.verify(X509CertImpl.java:456)
    at java.base/sun.security.provider.certpath.BasicChecker.verifySignature(BasicChecker.java:166)
    at java.base/sun.security.provider.certpath.BasicChecker.check(BasicChecker.java:147)
    at java.base/sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:125)
    ... 25 more
$

# This results in the same error as above
$ ./jdk-11.0.6+10/bin/java SSLPoke www.cloudflare.com 443

✨

What I find particularly surprising is that the results do not change even when another cacert-file is used.

The Raspbian java is still happily validating the domains based on the cacert-file from AdoptOpenJDK.

The AdoptOpenJDK java is also consistent even when handed the Raspbian provided cacert-file:

# Testing cacert from AdoptOpenJDK with Raspbian java
$ sudo mv /etc/ssl/certs/java/cacerts /etc/ssl/certs/java/cacerts__
$ java -Djava.security.debug=all -Djavax.net.ssl.trustStore=jdk-11.0.6+10/lib/security/cacerts -Djavax.net.ssl.trustStorePassword=changeit SSLPoke www.cloudflare.com 443 2>&1 | grep 'validation succeeded'
certpath: -checker1 validation succeeded
certpath: -checker2 validation succeeded
certpath: -checker3 validation succeeded
certpath: -checker4 validation succeeded
certpath: -checker5 validation succeeded
certpath: -checker6 validation succeeded
certpath: -checker7 validation succeeded
cert1 validation succeeded.
certpath: -checker1 validation succeeded
certpath: -checker2 validation succeeded
certpath: -checker3 validation succeeded
certpath: -checker4 validation succeeded
certpath: -checker5 validation succeeded
certpath: -checker6 validation succeeded
certpath: -checker7 validation succeeded
cert2 validation succeeded.
certpath: Cert path validation succeeded. (PKIX validation algorithm)

# Testing cacert from Raspbian with AdoptOpenJDK java
$ ./jdk-11.0.6+10/bin/java -Djava.security.debug=all -Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacerts__ -Djavax.net.ssl.trustStorePassword=changeit SSLPoke www.cloudflare.com 443 2>&1 | grep 'validation succeeded'
certpath: -checker1 validation succeeded
certpath: -checker2 validation succeeded
certpath: -checker3 validation succeeded
certpath: -checker4 validation succeeded
certpath: -checker5 validation succeeded
certpath: -checker6 validation succeeded
certpath: -checker7 validation succeeded
cert1 validation succeeded.
certpath: -checker1 validation succeeded
certpath: -checker2 validation succeeded
certpath: -checker3 validation succeeded
certpath: -checker4 validation succeeded
certpath: -checker5 validation succeeded
$

I got similar results when testing jdk8u232-b09-jre on the same platform (armv7l).

Refs https://github.com/arduino/Arduino/issues/9719

[cmaglie]

Sorry the previous message was not meant to be sent here, I sent it by mistake, my apologies.

Anyway, I hope it helps to narrow down the issue.

[karianna]

Sorry the previous message was not meant to be sent here, I sent it by mistake, my apologies.

Anyway, I hope it helps to narrow down the issue.

Argh, I deleted it by accident, can you link to the original message?

[cmaglie]

https://github.com/arduino/Arduino/issues/9719#issuecomment-583066985

[aahlenst]

Problems with ARMv7 have been fixed some time ago. AdoptOpenJDK 15 contains a new cacerts keystore containing the same set of certificates as Firefox (and most of the Linux distributions). The October updates for 8 and 11 will get the same keystore.

If new problems appear or old ones persist, please open a new issue.