Hi Sean, thanks for looking into it .
>However, there is no nextUpdate field set, which means there should be always
>newer information available. So while the 5 minute delay may not be a huge
>issue, the fact that they are returning cached responses,
>looks like a problem to me.This could be the underlying problem, in that they
>are not generating fresh OCSPResponses. I will contact LuxTrust and see if we
>can get some information from them.
Can we exclude the test until the issue is resolved ?
We see such failures very often .
Best regards, Matthias
From: Sean Mullan <sean.mul...@oracle.com>
Sent: Donnerstag, 23. Januar 2020 21:46
To: Baesken, Matthias <matthias.baes...@sap.com>; security-dev@openjdk.java.net
Subject: Re: jtreg test
security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java
instabilities
On 1/17/20 8:09 AM, Baesken, Matthias wrote:
Hello, I wonder if you have some input regarding the following issue.
I noticed a couple of instabilities (in jdk13 and higher) in the test
security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java
.
The test sometimes fails when validating the "validity interval" of OCSP
responses :
Example output is like :
certpath: OCSP response validity interval is from Wed Dec 04 01:05:27 CET 2019
certpath: Checking validity of OCSP response on: Wed Dec 04 01:39:15 CET 2019
<--------- default interval is system time "on" machine +/- 15
minutes , this is seen as valid by OpenJDK
...
java.lang.RuntimeException: TEST FAILED: couldn't determine EE certificate
status
at
ValidatePathWithParams.validate(ValidatePathWithParams.java:177)
at LuxTrustCA.main(LuxTrustCA.java:186)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at
com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
at java.base/java.lang.Thread.run(Thread.java:832)
stdout contains :
Received exception: java.security.cert.CertPathValidatorException: Response is
unreliable: its validity interval is out-of-date
So our system time "on" machine ( 01:39:15 CET 2019 +/- 15 minutes )
does not contain the time from OCSP response ( 01:05:27 CET 2019) .
Reason is unclear , of course the time on the test machine could be wrong
but we see the issue on multiple machines and when looking into the system
times of the machines they look fine .
Maybe the time info from the OCSP response is wrong , at least it looks
like this is the issue here .
Have you seen similar issues (also in other tests dealing with OCSP response
validity checks) ?
Yes, I can confirm we have seen this at least once before. There is a bug filed
for it, but it is currently marked Confidential because it has some internal
information in it.
Can you send me the whole log file or at least more of it which shows the info
below?
Do you think that increasing the acceptance interval e.g. by setting it
to -Dcom.sun.security.ocsp.clockSkew=9000000 in
security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java
would be okay ?
( I'd like to add a little bit more tracing too so that in case of such errors
it is easier to understand the issue )
No that would be too much skew. If there is an issue with the time on the OCSP
Responder, that is a more serious issue which this property might mask.
I just ran this test myself locally. I noticed that one of the OCSP Responders
appears to be returning pre-produced OCSPResponses:
certpath: connecting to OCSP service at: http://qca.ocsp.luxtrust.lu
certpath: OCSP response status: SUCCESSFUL
certpath: OCSP response type: basic
certpath: Responder ID: byKey: AFC136FF2B78DC9F78E0100F2ABC24DDBD6F12B6
certpath: OCSP response produced at: Thu Jan 23 15:23:08 EST 2020
certpath: OCSP number of SingleResponses: 1
certpath: thisUpdate: Thu Jan 23 15:18:13 EST 2020
However, there is no nextUpdate field set, which means there should be always
newer information available. So while the 5 minute delay may not be a huge
issue, the fact that they are returning cached responses, looks like a problem
to me.
This could be the underlying problem, in that they are not generating fresh
OCSPResponses. I will contact LuxTrust and see if we can get some information
from them.
Thanks,
Sean
