[ 
https://issues.apache.org/jira/browse/CXF-2688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12840772#action_12840772
 ] 

Cyrille Le Clerc edited comment on CXF-2688 at 3/3/10 6:18 PM:
---------------------------------------------------------------

I am very sorry for this trouble. The reasons I pushed this feature are that I 
saw the "trust all certs" work was started in the code, I knew to [Jakarta 
Commons Http Client 
EasySSLProtocolSocketFactory.java|http://svn.apache.org/viewvc/httpcomponents/oac.hc3x/trunk/src/contrib/org/apache/commons/httpclient/contrib/ssl/EasySSLProtocolSocketFactory.java?view=markup]
 and I saw many pains on projects due to self signed certificates for dev 
environments.

As an intermediate solution between the silent implementation I pushed and the 
complete removal, I am looking at a solution that would write a detailed 
warning log message each time an untrusted certificate is processed.

I am looking at the SSL APIs to see how the default trust manager is 
instantiated if none has been provided. As all the JSSE code's documentation is 
limited due to export restrictions, it may take may few hours. 



      was (Author: cleclerc):
    I am very sorry for this trouble. The reasons I pushed this feature is that 
I saw the "trust all certs" work was started in the code, I knew to [Jakarta 
Commons Http Client 
EasySSLProtocolSocketFactory.java|http://svn.apache.org/viewvc/httpcomponents/oac.hc3x/trunk/src/contrib/org/apache/commons/httpclient/contrib/ssl/EasySSLProtocolSocketFactory.java?view=markup]
 and I saw many pains on projects due to self signed certificates for dev 
environments.

As an intermediate solution between the silent implementation I pushed and the 
complete removal, I am looking at a solution that would write a detailed 
warning log message each time an untrusted certificate is processed.

I am looking at the SSL APIs to see how the default trust manager is 
instantiated if none has been provided. As all the JSSE code's documentation is 
limited due to export restrictions, it may take may few hours. 


  
> Allow deactivation of SSL X509 Certificates validation
> ------------------------------------------------------
>
>                 Key: CXF-2688
>                 URL: https://issues.apache.org/jira/browse/CXF-2688
>             Project: CXF
>          Issue Type: New Feature
>          Components: Transports
>    Affects Versions: 2.2.6
>            Reporter: Cyrille Le Clerc
>            Assignee: Cyrille Le Clerc
>             Fix For: 2.2.7
>
>         Attachments: CXF-2688.diff
>
>
> CXF client (JAXWS & JAXRS) for HTTPS calls currently only allows to disable 
> hostname verification ({{<http-conf:tlsClientParameters disableCNCheck="true" 
> />}}) but does not allow to disable X509 certificates checking.
> Due to this, it can be painful to invoke services with self-signed 
> certificates on non-production environments (see sample stacktrace below).
> Here is a proposal to disable all X509 certificates in CXF (JAXWS & JAXRS) 
> clients :
> * Add boolean attribute {{trustAllCertificates}} to 
> {{<http-conf:tlsClientParameters ... />}},
> * In the {{HTTPConduit}}, if {{trustAllCertificates="true"}}, the 
> {{HttpsURLConnectionFactory}} will use an 'accept all certificates' 
> {{javax.net.ssl.X509TrustManager}} and an 'accept all' 
> {{javax.net.ssl.HostnameVerifier}}.
> *Note* : this proposal adds an attribute {{trustAllCertificates}} to the 
> {{TLSClientParametersType}} complex type and thus *this proposal requires to 
> publish a new 'backward compatible' 
> [http://cxf.apache.org/schemas/configuration/security.xsd]*. 
> Configuration sample enabling 'trustAllCertificates' to invoke an HTTPS 
> service:
> {code:xml}
> <jaxws:client id="helloWorldServiceClient"
>    serviceClass="com.example.HelloWorldService"
>    address="https://example.com/services/helloWorldService";>
> </jaxws:client>
> <http-conf:conduit 
> name="{http://example.com/}HelloWorldServicePort.http-conduit";>
>    <!-- trust all certificates (self signed certificates, etc) -->
>    <http-conf:tlsClientParameters trustAllCertificates="true" />
>    
>    <http-conf:authorization>
>       <security:UserName>my-user-name</security:UserName>
>       <security:Password>my-password</security:Password>
>    </http-conf:authorization>
> </http-conf:conduit>
> {code}
> CXF client exception's stacktrace with a self-signe certificate: 
> {noformat}
> 2010/03/01 22:05:23,682  WARN [http-8080-1] 
> org.apache.cxf.phase.PhaseInterceptorChain - Interceptor for 
> {http://example.com/}HelloWorldServiceService#{http://example.com/}sayHi has 
> thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault: Could not send Message.
>       at 
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:64)
>       ...
>       at 
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
>       at $Proxy69.sayHi(Unknown Source)
>       ...
> Caused by: javax.net.ssl.SSLHandshakeException: 
> sun.security.validator.ValidatorException: PKIX path building failed: 
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target
>       ...
> Caused by: sun.security.validator.ValidatorException: PKIX path building 
> failed: 
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target
>       ...
> Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable 
> to find valid certification path to requested target
>       ...
> {noformat}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to