it's fixed with CXF-6000 in 3.1.0, 3.0.2, and 2.7.13. thanks.
2014-09-12 18:29 GMT+02:00 Aki Yoshida <[email protected]>: > hi joerg, > umm. you may be right. > I looked at the cxf's code and see that is using KeyManagerFactory's > default for both KeyManager and TrustManager. > TrustManagerFactory's default is in fact PKIX, so if its value is used > for the TrustManager instantiation instead, it should be working. > i'll will verify this. > regards, aki > > 2014-09-12 12:24 GMT+02:00 Kessler, Joerg <[email protected]>: >> Hi Aki, >> Yes, that solves the problem. No, I did not configure it for the system >> properties trust store access. I assume that activating of OCSP/CRL (using >> com.sun.security.enableCRLDP and com.sun.net.ssl.checkRevocation) somehow >> changes the default implicitly and CXF is not aware of that. I simply did >> not know that you can configure the algorithm (and in case one wants to use >> OCSP/CRL you must configure it). I still have some doubts because a user >> might not expect that he has to configure it and if he does not test it this >> security measure does not work although he thinks it is active. >> >> Thanks and best regards, >> >> Jörg >> >> -----Original Message----- >> From: Aki Yoshida [mailto:[email protected]] >> Sent: Freitag, 12. September 2014 00:24 >> To: [email protected] >> Subject: Re: Problem using OCSP and truststore configuration in the http >> conduit >> >> i'm not sure what needs to be done. So this is just a guess. >> what do you set at the factoryAlgorithm property of your CXF's >> TrustManager configuration? Is it set to PKIX? >> >> <sec:trustManagers factoryAlgorithm="PKIX"> >> >> Could it be that you are setting the algorithm explicitly in your >> non-cxf program but not in the cxf's configuration? >> >> 2014-09-08 15:12 GMT+02:00 Kessler, Joerg <[email protected]>: >>> Hi, >>> I am testing OCSP together with a CXF WS consumer. I am addressing my own >>> trust store in the http conduit. I created my own CA and a certificate >>> (localhost) holding the location url of the validation service (on my >>> computer). The scenario is CXF->https://localhost->CXF. OCSP is supported >>> by the JDK since Java 5. So I expected no problems. But when sending >>> messages the validation url is not called to check the certificate and no >>> error occurs. I did a lot of experiments and found out that it works when I >>> set the trust store using the system property javax.net.ssl.trustStore >>> instead of the conduit. I tried to debug the problem and found that >>> com.sun.net.ssl.internal.ssl.TrustManagerFactoryImpl provides two classes: >>> PKIXFactory and SimpleFactory. When PKIXFactory was instantiated then it >>> worked (verifier was called), using SimpleFactory it did not work. I could >>> even change the algorithm in the debugger from 'simple' to 'PKIX' and then >>> it worked. But I was unable figure out when and why 'PKIX' or 'simple' is >>> set. I came to the class >>> javax.net.ssl.TrustManagerFactory->getDefaultAlgorithm() that seems to >>> return the value somehow. But finally I got stuck. The problem seems to be >>> caused by the method how CXF provides the trust store for ssl communication. >>> >>> I can provide two simple tests that demonstrate the problem and should run >>> on any local environment. One using the system property that fails due to >>> the missing validation service (verified by the ssl debug trace) and one >>> using the conduit that is always successful because no validation is >>> called. Both use the same certificate/trust store. >>> >>> Best Regards, >>> >>> Jörg >>>
