cxf-issues mailing list archives

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


Glen Mazza commented on CXF-2688:

I just need to have this sanity checked by a couple more CXF committers (there's about 25-30
of us, so that should not be too hard).  I do not like this change, but if a couple of others
are OK it, it is not worth vetoing.

It is beneficial for a product to be robust enough, to have protective mechanisms so that
even if total newbie developers work with it, there is little or no security loss that can
occur.  We don't want people's credit card numbers or other sensitive data to be stolen.

The reason for introducing this potential security hole--to help newbies who don't know how
to work with self-signed certs--is disconcerting.  How sure can we be that such people indeed
will remember to set trustAllCertificates back to "false" for production time?  If they are
not going to learn about certs during development how are they going to learn it production
time?  Further, should such people who stumble over certificate usage really be programming
secure web services to begin with?


> 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.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