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

[Sean Mullan]

On 1/24/20 3:40 AM, Baesken, Matthias wrote:
> 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 ?

Ok, that is fine with me.

Thanks,
Sean

> 
> 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
>