Problem using OCSP and truststore configuration in the http conduit

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Problem using OCSP and truststore configuration in the http conduit

Kessler, Joerg
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

Reply | Threaded
Open this post in threaded view
|

Re: Problem using OCSP and truststore configuration in the http conduit

Aki Yoshida-3
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 <[hidden email]>:
> 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
>
Reply | Threaded
Open this post in threaded view
|

RE: Problem using OCSP and truststore configuration in the http conduit

Kessler, Joerg
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:[hidden email]]
Sent: Freitag, 12. September 2014 00:24
To: [hidden email]
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 <[hidden email]>:
> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Problem using OCSP and truststore configuration in the http conduit

Aki Yoshida-3
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 <[hidden email]>:

> 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:[hidden email]]
> Sent: Freitag, 12. September 2014 00:24
> To: [hidden email]
> 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 <[hidden email]>:
>> 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
>>
Reply | Threaded
Open this post in threaded view
|

Re: Problem using OCSP and truststore configuration in the http conduit

Aki Yoshida-3
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 <[hidden email]>:

> 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 <[hidden email]>:
>> 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:[hidden email]]
>> Sent: Freitag, 12. September 2014 00:24
>> To: [hidden email]
>> 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 <[hidden email]>:
>>> 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
>>>