cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cyrille Le Clerc (JIRA)" <>
Subject [jira] Commented: (CXF-2688) Allow deactivation of SSL X509 Certificates validation
Date Thu, 11 Mar 2010 17:27:27 GMT


Cyrille Le Clerc commented on CXF-2688:

As discussed on the dev mailing list message [\[CXF-2688\] "Allow deactivation of SSL X509
Certificates validation" reverted|],
an alternate solution has been implemented.

CXF 2.2.7 integrates CXF-2693 "Allow to use HttpsURLConnection's defaultSSLSocketFactory and
defaultHostnameVerifier in CXF client". Thanks to this, users will be able to disable all
ssl verifications at the JVM level with an "Accept All Ssl Socket Factory" and an "Accept
All Hostname Verifier" and then configure CXF to rely on them. *Please note that disabling
ssl verifications is a severe security breach.*

An advantage of the JVM wide approach is to encourage users to disable ssl verifications during
the middleware startup phase rather than in the application and thus to mitigate the risk
to inadvertently disable ssl verifications on productions.

For Tomcat users, I developed an [Accept All Ssl Certificates Listener|]
which disables SSL verifications during Tomcat startup and emits meaningful warning messages
for untrusted certificates to help debugging. 

> Allow deactivation of SSL X509 Certificates validation
> ------------------------------------------------------
>                 Key: CXF-2688
>                 URL:
>             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-enhanced-warnings.patch, 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' {{}} and an 'accept all'
> *Note* : this proposal adds an attribute {{trustAllCertificates}} to the {{TLSClientParametersType}}
complex type and thus *this proposal requires to publish a new 'backward compatible' []*.

> Configuration sample enabling 'trustAllCertificates' to invoke an HTTPS service:
> {code:xml}
> <jaxws:client id="helloWorldServiceClient"
>    serviceClass="com.example.HelloWorldService"
>    address="">
> </jaxws:client>
> <http-conf:conduit name="{}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 
> {}HelloWorldServiceService#{}sayHi has thrown exception,
unwinding now
> org.apache.cxf.interceptor.Fault: Could not send Message.
> 	at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(
> 	...
> 	at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(
> 	at $Proxy69.sayHi(Unknown Source)
> 	...
> Caused by:
PKIX path building failed: 
> unable to find valid certification
path to requested target
> 	...
> Caused by: PKIX path building failed: 
> unable to find valid certification
path to requested target
> 	...
> Caused by: 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.

View raw message