Mailing-List: contact users-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cxf.apache.org
Received-SPF: pass (nike.apache.org: domain of elakito@gmail.com designates
 209.85.215.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAF8t5XsR1L4WHTjdNXKYmJs9w55yjM1YVFCQ9jAtLi5+akE4cw@mail.gmail.com>
References: 
 <93E45CF9F9683B458EC51BFC39F106DD271A950E@DEWDFEMB16B.global.corp.sap>
	<CAF8t5XuH_inNgJ5JJB_HLnh9XC6uJvobBmYG+wUbXn4jRFDyBQ@mail.gmail.com>
	<93E45CF9F9683B458EC51BFC39F106DD271B53FE@DEWDFEMB16B.global.corp.sap>
	<CAF8t5XsR1L4WHTjdNXKYmJs9w55yjM1YVFCQ9jAtLi5+akE4cw@mail.gmail.com>
Date: Fri, 12 Sep 2014 18:57:48 +0200
Message-ID: 
 <CAF8t5Xt_81J0Jaducn3ipBFLSez4pOEgOO35QaYa6T=u+VZ_SQ@mail.gmail.com>
Subject: Re: Problem using OCSP and truststore configuration in the http
 conduit
From: Aki Yoshida <elakito@gmail.com>
To: users@cxf.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 <elakito@gmail.com>:
> 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 <joerg.kessler@sap.com>:
>> 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 m=
ight 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=C3=B6rg
>>
>> -----Original Message-----
>> From: Aki Yoshida [mailto:elakito@gmail.com]
>> Sent: Freitag, 12. September 2014 00:24
>> To: users@cxf.apache.org
>> 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=3D"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 <joerg.kessler@sap.com>:
>>> Hi,
>>> I am testing OCSP together with a CXF WS consumer. I am addressing my o=
wn 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 compu=
ter).  The scenario is CXF->https://localhost->CXF.  OCSP is supported by t=
he JDK since Java 5. So I expected no problems. But when sending messages t=
he validation url is not called to check the certificate and no error occur=
s. I did a lot of experiments and found out that it works when I set the tr=
ust 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.inte=
rnal.ssl.TrustManagerFactoryImpl provides two classes: PKIXFactory and Simp=
leFactory. When PKIXFactory was instantiated then it worked (verifier was c=
alled), using SimpleFactory it did not work. I could even change the algori=
thm in the debugger from 'simple' to 'PKIX' and then it worked. But I was u=
nable figure out when and why 'PKIX' or 'simple'  is set. I came to the cla=
ss javax.net.ssl.TrustManagerFactory->getDefaultAlgorithm() that seems to r=
eturn the value somehow. But finally I got stuck. The problem seems to be c=
aused 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 call=
ed. Both use the same certificate/trust store.
>>>
>>> Best Regards,
>>>
>>> J=C3=B6rg
>>>