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

Fri, 24 Jan 2020 12:12:23 -0800 

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

Reply via email to