Bug ID: JDK-8314509 LuxTrustCA.java fails on machines that cannot reach CA

JDK-8314509 : LuxTrustCA.java fails on machines that cannot reach CA

Type: Bug
Component: security-libs
Sub-Component: jdk.security
Affected Version: openjdk8u252,11.0.6,17,20,21,22

Priority: P4
Status: In Progress
Resolution: Unresolved

Submitted: 2023-08-17
Updated: 2024-08-15

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 24
24Unresolved

Related Reports

Relates :

JDK-8232019 - Add LuxTrust certificate updates to the existing root program

Description

Easiest way to reproduce is:
 1. Add "127.0.0.1 crl.luxtrust.lu" to /etc/hosts
 2. Run:

```
$ CONF=macosx-aarch64-server-fastdebug make test TEST=security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java

TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: TEST FAILED: couldn't determine EE certificate status


java.lang.RuntimeException: TEST FAILED: couldn't determine EE certificate status
	at ValidatePathWithParams.validate(ValidatePathWithParams.java:177)
	at LuxTrustCA.main(LuxTrustCA.java:187)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.run(Thread.java:1570)
Caused by: java.security.cert.CertPathValidatorException: Unable to determine revocation status due to network error
	at java.base/sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:135)
	at java.base/sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:224)
	at java.base/sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:144)
	at java.base/sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:83)
	at java.base/java.security.cert.CertPathValidator.validate(CertPathValidator.java:309)
	at ValidatePathWithParams.doCertPathValidate(ValidatePathWithParams.java:288)
	at ValidatePathWithParams.validate(ValidatePathWithParams.java:142)
	... 5 more
Caused by: sun.security.provider.certpath.PKIX$CertStoreTypeException: java.net.ConnectException: Connection refused
	at java.base/sun.security.provider.certpath.URICertStore.engineGetCRLs(URICertStore.java:438)
	at java.base/java.security.cert.CertStore.getCRLs(CertStore.java:182)
	at java.base/sun.security.provider.certpath.DistributionPointFetcher.getCRL(DistributionPointFetcher.java:236)
	at java.base/sun.security.provider.certpath.DistributionPointFetcher.getCRLs(DistributionPointFetcher.java:179)
	at java.base/sun.security.provider.certpath.DistributionPointFetcher.getCRLs(DistributionPointFetcher.java:110)
	at java.base/sun.security.provider.certpath.RevocationChecker.checkCRLs(RevocationChecker.java:583)
	at java.base/sun.security.provider.certpath.RevocationChecker.checkCRLs(RevocationChecker.java:470)
	at java.base/sun.security.provider.certpath.RevocationChecker.check(RevocationChecker.java:373)
	at java.base/sun.security.provider.certpath.RevocationChecker.check(RevocationChecker.java:343)
	at java.base/sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:125)
	... 11 more
Caused by: java.net.ConnectException: Connection refused
	at java.base/sun.nio.ch.Net.pollConnect(Native Method)
	at java.base/sun.nio.ch.Net.pollConnectNow(Net.java:682)
	at java.base/sun.nio.ch.NioSocketImpl.timedFinishConnect(NioSocketImpl.java:542)
	at java.base/sun.nio.ch.NioSocketImpl.connect(NioSocketImpl.java:592)
	at java.base/java.net.Socket.connect(Socket.java:751)
```

Comments

We also see this occasionally fail due to retrieving the CRL (get network resets when visiting the URL). In the JTR file it looks like this: certpath: DistributionPointFetcher.getCRLs: Checking CRLDPs for CN=LuxTrust Global Qualified CA 3, O=LuxTrust S.A., C=LU certpath: Trying to fetch CRL from DP http://crl.luxtrust.lu/LTGRCA2.crl certpath: CertStore URI:http://crl.luxtrust.lu/LTGRCA2.crl certpath: Exception fetching CRL: java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:210) at java.net.SocketInputStream.read(SocketInputStream.java:141) at java.io.BufferedInputStream.fill(BufferedInputStream.java:246) at java.io.BufferedInputStream.read1(BufferedInputStream.java:286) at java.io.BufferedInputStream.read(BufferedInputStream.java:345) at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:743) at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:678) at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:702) at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1595) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1500) at sun.security.provider.certpath.URICertStore.engineGetCRLs(URICertStore.java:396) at java.security.cert.CertStore.getCRLs(CertStore.java:181) at sun.security.provider.certpath.DistributionPointFetcher.getCRL(DistributionPointFetcher.java:269) at sun.security.provider.certpath.DistributionPointFetcher.getCRLs(DistributionPointFetcher.java:213) at sun.security.provider.certpath.DistributionPointFetcher.getCRLs(DistributionPointFetcher.java:144) at sun.security.provider.certpath.RevocationChecker.checkCRLs(RevocationChecker.java:579) at sun.security.provider.certpath.RevocationChecker.checkCRLs(RevocationChecker.java:464) at sun.security.provider.certpath.RevocationChecker.check(RevocationChecker.java:366) at sun.security.provider.certpath.RevocationChecker.check(RevocationChecker.java:336) at sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:125) at sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:220) at sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:140) at sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:79) at java.security.cert.CertPathValidator.validate(CertPathValidator.java:292) at ValidatePathWithParams.doCertPathValidate(ValidatePathWithParams.java:288) at ValidatePathWithParams.validate(ValidatePathWithParams.java:142) at LuxTrustCA.main(LuxTrustCA.java:186) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.lang.Thread.run(Thread.java:750) When trying to visit http://crl.luxtrust.lu/LTGRCA2.crl in a browser I get the same connection reset. Using curl to illustrate: $ curl -v http://crl.luxtrust.lu/LTGRCA2.crl * processing: http://crl.luxtrust.lu/LTGRCA2.crl * Trying 185.69.225.3:80... * Connected to crl.luxtrust.lu (185.69.225.3) port 80 > GET /LTGRCA2.crl HTTP/1.1 > Host: crl.luxtrust.lu > User-Agent: curl/8.2.1 > Accept: / > * Recv failure: Connection reset by peer * Closing connection curl: (56) Recv failure: Connection reset by peer See: https://github.com/jerboaa/jdk8u-dev/actions/runs/8391279796/job/22981788234#step:10:12
22-03-2024
I will also consider to update ValidatePathWithParams template to throw jtreg.SkippedException on network failures.
17-10-2023
Following loop will look for all causes: Throwable cause = cpve; do { cause = cause.getCause(); if (cause instanceof IOException) { out.println("WARNING: CertPathValidatorException caused by IO" + " error, skip this test"); return; } else { out.println("Cause: " + cause); } } while (cause != null);
17-10-2023
The best I can come up with without intrusive hacks into RevocationChecker is: ``` diff --git a/test/jdk/security/infra/java/security/cert/CertPathValidator/certification/ValidatePathWithParams.java b/test/jdk/security/infra/java/security/cert/CertPathValidator/certification/ValidatePathWithParams.java index c8a7426cd7e..e6855eecc1b 100644 --- a/test/jdk/security/infra/java/security/cert/CertPathValidator/certification/ValidatePathWithParams.java +++ b/test/jdk/security/infra/java/security/cert/CertPathValidator/certification/ValidatePathWithParams.java @@ -156,6 +156,12 @@ public class ValidatePathWithParams { return; } + if (cpve.getReason() == CertPathValidatorException.BasicReason.UNDETERMINED_REVOCATION_STATUS) { + out.println("WARNING: Cannot determine certificate status, " + + "assume network error, skip this test"); + return; + } + if (cpve.getReason() == CertPathValidatorException.BasicReason.ALGORITHM_CONSTRAINED) { out.println("WARNING: CertPathValidatorException caused by" + " restricted algorithm, skip this test"); ``` ...but that feels unsatisfactory.
21-08-2023
Right. The test already does it when it captures IOException. The problem here is that exception is getting (re-)wrapped in various specific exceptions. If I unpack those, then the test still fails, because certvalidator throws unchained exceptions from inside, etc. That's why my naive attempt at fixing it stalled :)
17-08-2023
Test is failing when revocation check fails with network error. Test may be updated to throw JTReg SkippedException in such cases.
17-08-2023