jtreg test security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java instabilities

[Baesken, Matthias]

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.mullan at oracle.com>
Sent: Donnerstag, 23. Januar 2020 21:46
To: Baesken, Matthias <matthias.baesken at sap.com>; security-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20200124/c1b760ae/attachment.htm>