JDK-8179502 : Enhance OCSP, CRL and Certificate Fetch Timeouts
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 8,9
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2017-05-02
  • Updated: 2025-01-17
  • Resolved: 2023-05-23
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 17 JDK 21
17.0.15-oracleFixed 21 b24Fixed
Related Reports
CSR :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Sub Tasks
JDK-8308460 :  
JDK-8308582 :  
Description
A DESCRIPTION OF THE REQUEST :
The current OCSP implementation of  Java has the unit of timeout in seconds. This means that the OCSP client will have to wait for min. 1 sec before timing out the connection. 1 sec is a huge amount of time in modern electronic communications. I request that in the default OCSP the timeout is changed from seconds to miliseconds.

Below is the problematic code : 

Class : sun.security.provider.certpath.OCSP

private static final int DEFAULT_CONNECT_TIMEOUT = 15000;
private static final int CONNECT_TIMEOUT = initializeTimeout();

private static int initializeTimeout() {
         Integer tmp = java.security.AccessController.doPrivileged(
                 new GetIntegerAction("com.sun.security.ocsp.timeout"));
         if (tmp == null || tmp < 0) {
             return DEFAULT_CONNECT_TIMEOUT;
         }
         // Convert to milliseconds, as the system property will be
         // specified in seconds
         return tmp * 1000;
}

In this we can clearly see that the min non zero value returned from initializeTimeout() method would be 1000 miliseconds (1sec)



JUSTIFICATION :
The current OCSP implementation of  Java the unit of timeout is seconds. This means that the OCSP client will have to wait for min. 1 sec before timing out the connection. 1 sec is a huge amount of time in modern electronic communications. I request that in the default OCSP the timeout is changed from seconds to miliseconds.

In addition, two other related enhancements should be made:
1. Properties that deal with CRL fetching and reading (com.sun.security.crl.timeout and com.sun.security.crl.readtimeout) should also be extended to allow for millisecond granularity.
2. Properties that fetch certificates based on the AIA extension should have configurable timeouts.  This will require two new properties: com.sun.security.cert.timeout and com.sun.security.cert.readtimeout.  These will be specified with the same syntax as the properties above (numeric value only interpreted as seconds, a numeric value ending in case-insensitive "ms" to be interpreted in milliseconds).  In addition, these property timeouts will only be acted upon when the com.sun.security.enableAIAcaIssuers property is set to true, as this is required for certificate fetching from the AIA extension.




Comments
Fix request [17u] Oracle plans to add this enhancement to 17.0.15-oracle I'd like to backport it for parity with Oracle. Risk minimum, compatibility issue is addressed
08-01-2025

Hi [~goetz], CSR https://bugs.openjdk.org/browse/JDK-8337407 is approved and PR is reviewed. Oracle agreed on the implementation with JDK17 backward compatibility fix: https://github.com/openjdk/jdk17u-dev/pull/2747 (see discussion in https://bugs.openjdk.org/browse/JDK-8345114)
07-01-2025

Hi [~aph], the reason stated for this backport is "parity with Oracle". But Oracle did not yet integrate this backport. Probably they have a good reason not to do so. I commented about this in the PR. Also, if they do so, the corresponding documentation will get updated, if they don't but we do, the documentation will be wrong. Further, as this is a larger change in a delicate part of the JVM having listed four related issues (two of them not relevant for the backport), I don't buy that the risk is low. JDK-8309754 still has no solution.
11-11-2024

[~goetz], why is this one deferred? I know some people are waiting for it.
11-11-2024

Fix request [17u] I'd like to backport this enhancement to improve the timeout adjustment for OCSP GET requests and parity with Oracle. Risk is minimal. All related tests are passed.
25-10-2024

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk17u-dev/pull/2754 Date: 2024-07-31 13:53:39 +0000
20-08-2024

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk17u-dev/pull/2747 Date: 2024-07-28 22:02:37 +0000
28-07-2024

Created JDK-8309740 to deal with this issue.
09-06-2023

[~mbaesken] One other question related to the above test failures: The tests run multiple times with different combinations of client/server timeout values. For each of the three tests, is it just one combination of client/server timeouts that has issues, or multiple combinations? Knowing which ones are problematic in your environment would be helpful.
09-06-2023

That was my fear. Sounds like the timeout windows need to be loosened across all three tests. Thanks for the info.
09-06-2023

> Out of curiosity, there are two other tests as part of this fix that have similar timeout windows...have they been running OK? I see 12 failures since May (introduction of the new tests) for the test CRLReadTimeout.java , they look like this (failures are mostly from Linux) : --------------------------------------------------- :stdErr: Sat Jun 03 21:17:24 CEST 2023 STATUS:Passed. -------------------------------- STATUS:Passed. -------------------------------- STATUS:Passed. -------------------------------- STATUS:Passed. -------------------------------- java.lang.RuntimeException: Expected to pass, found 1 soft fail exceptions at CRLReadTimeout.testTimeout(CRLReadTimeout.java:117) at CRLReadTimeout.main(CRLReadTimeout.java:77) 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:1583) Regarding OCSPTimeout.java I see 4 failures , all from Windows . Example : STATUS:Passed. -------------------------------- STATUS:Passed. -------------------------------- STATUS:Passed. -------------------------------- STATUS:Passed. -------------------------------- STATUS:Passed. -------------------------------- java.lang.RuntimeException: Expected to pass, found 1 soft fail exceptions at OCSPTimeout.main(OCSPTimeout.java:116) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:578) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1583)
09-06-2023

[~mbaesken] These timeout-exercising tests always make me a bit nervous when I have to write them. I run hundreds of iterations on mach5, but they always seem to behave a bit differently when run in a full-blown CI environment. In this case, I think I allowed a margin of 500 - 750ms for the server to return the certificate to the client. In my testing it was long enough, but apparently not when it gets into CI. I'm pretty sure expanding that window would be sufficient to allow the test to run to completion consistently. I will file a bug and look into this. Other than that, the test should contain all the resources it needs within the test body itself. Out of curiosity, there are two other tests as part of this fix that have similar timeout windows...have they been running OK?
09-06-2023

JDK-8179502 introduced a new test sun/security/x509/URICertStore/AIACertTimeout.java . This one fails rather often (approx. every day) on various test machines (mostly Linux). 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:146) at java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:127) at java.base/java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297) at AIACertTimeout.main(AIACertTimeout.java:96) 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:1583) Any idea what might happen here ? Does the test maybe require something that is problematic on our infrastructure ?
09-06-2023

Changeset: 2836c34b Author: Jamil Nimeh <jnimeh@openjdk.org> Date: 2023-05-23 21:32:28 +0000 URL: https://git.openjdk.org/jdk/commit/2836c34b64e4626e25c86a53e5bef2bf32f95d2e
23-05-2023

[~rgallard] I have created JDK-8308460 as a doc subtask. I've added a couple recent changes to the CSR and that has been linked to the doc subtask for ease of reference.
19-05-2023

[~jnimeh] Please add a release note and add a docs subtask for documenting the new syntax of the properties in the PKI Programmer's Guide. Also, it looks like the "com.sun.security.ocsp.timeout" property was never documented.
09-05-2023

A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/13762 Date: 2023-05-02 21:12:31 +0000
02-05-2023

I think this is a worthwhile enhancement. According to https://twitter.com/rmhrisk/status/322438951392657408 - the average OCSP response time is 250ms, so a timeout of less than 1 second does seem like it could be useful. However, we can't just change it to milliseconds as that would break anyone using seconds as the value. We could add a new property that takes the value in milliseconds, or maybe we could enhance the current property to recognize seconds as well as milliseconds as "ms", ex: "com.sun.security.ocsp.timeout=500ms".
03-05-2017