Re: wsdl_first_https

Glen Mazza Mon, 25 Jun 2012 08:26:18 -0700

Yes, Tomcat is embeddable:www.jroller.com/gmazza/entry/junit_web_service_testing#testtc.


Glen


On 06/25/2012 11:10 AM, Himanshu Gupta wrote:

Hello Glen,

Thanks for the quick response. I am using scenario 2.

With Scenario 2 and

1. not using "<sec:clientAuthentication want="true" required="true"/>"
2. importing the server sertificate on the JDK default keystore "cacerts"

I could see the wsdl in the web browser. The client in the sample also
works well. Also the Dynamic client also works, because it uses the default
keystore (you cannot change it for dynamic clients).

Everyone's Happy, but this means any one who needs to see the wsdl on the
browser would need to do 2 (i.e. import server cert on the jre default
keystore) :(( ...

Problem seems to be solved, but any Insights (explanations) would be
helpful.

PS : Glen, to your previous question, we can not use standalone tomcat, as
we have a standalone java server, and we need an embedded in memory
solution. please let me know, if this could be done using tomcat just like
jetty.

Thanks,
Himanshu.

On Mon, Jun 25, 2012 at 4:42 PM, Glen Mazza<[email protected]>  wrote:

Himanshu, of the wsdl_first_https sample, which of the four scenarios are
you running--per that sample's README, scenarios 1 and 3 are supposed to
fail due to lack of client credentials, while scenarios 2 and 4 should
work.  Also, is the problem with the running of the sample or just you
viewing it from the browser?

The blog entry you're referencing is from 2008 and covers the
long-obsoleted CXF 2.1 (our lowest supported version is now 2.4), I would
be surprised if that code still worked.  I'm not much familiar with the
Dynamic Client (I don't hear much about it today), whether it can/should
work with HTTPS (the docs for it do not give that indication[1]), hopefully
someone else can help you here or maybe the Nabble forums can help (
http://cxf.547215.n5.nabble.**com/template/NamlServlet.jtp?**
macro=search_page&node=547216&**query=dynamic+client+ssl<http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=search_page&node=547216&query=dynamic+client+ssl>).
  You might be better off with the more standard JAX-WS Dispatch method[2]
if you can't use stub-based calls.

Glen

[1] 
http://cxf.apache.org/docs/**dynamic-clients.html<http://cxf.apache.org/docs/dynamic-clients.html>
[2] http://www.jroller.com/gmazza/**entry/calling_rpc_encoded_web_**
services<http://www.jroller.com/gmazza/entry/calling_rpc_encoded_web_services>


On 06/25/2012 10:02 AM, Himanshu Gupta wrote:

Hello Colm,

In the sample wsdl_first_https, I removed line<sec:clientAuthentication
want="true" required="true"/>   from the server configuration. The Client
in
the example works well. But the Firefox fails, and still gives error
"javax.net.ssl.**SSLHandshakeException: no cipher suites in common" on
the
server.

Please let me know, If you want me to try something specific.

Sorry just looking for an appropriate solution :(

Thanks,
Himanshu.


On Mon, Jun 25, 2012 at 3:57 PM, Colm O hEigeartaigh<coheigea@apache.**
org<[email protected]>>wrote:

  Colm : I did add the certificates to for e.g. in the Firefox explicitly.

Yes, you added the certificates so that the browser trusted the service
endpoint. However, as I explained in my previous mail, the service
endpoint
requires that the client presents its own certificate + private key for
client authentication, hence the failure.

Colm.

On Mon, Jun 25, 2012 at 2:51 PM, Himanshu Gupta<[email protected]

wrote:
Hello Guys,

Colm : I did add the certificates to for e.g. in the Firefox explicitly.

Following

http://aruld.info/programming-**ssl-for-jetty-based-cxf-**services/<http://aruld.info/programming-ssl-for-jetty-based-cxf-services/>for

my Dynamic Client, I try to do somthing like below :

1. JaxWsDynamicClientFactory dcf =

JaxWsDynamicClientFactory.**newInstance();

2. Client client = dcf.createClient("

  https://localhost:9001/**ApexCollateral/ing/services/**

wss/agreementDemo/2.0?wsdl<https://localhost:9001/ApexCollateral/ing/services/wss/agreementDemo/2.0?wsdl>

");
3. configureSSLOnTheClient(**client);
4. Object[] res = client.invoke("**getAgreementDemoIdentifier", new
Integer(1));

Theoretically it should have worked, but it fails with an exception like
"org.apache.cxf.service.**factory.**ServiceConstructionException:
Could not
resolve URL 
"https://localhost:9001/**someService/2.0?wsdl<https://localhost:9001/someService/2.0?wsdl>".",
while
excetuing *line number 2 (*logs attached*) *that is even before line 3
where I could setup the truststore, manually.

I really want to use the Dynamic Client approach in the test cases to

test

my web services. I assume, along with the testing services, with this
approach I also validate auto code generation for clients, which would
be
used eventually by the consumers (by exposed wsdls).

Please help,

Thanks,
Himanshu.


On Mon, Jun 25, 2012 at 2:51 PM, Glen Mazza<[email protected]>   wrote:

  Personally, for SSL, I would recommend using a standalone servlet

container like Tomcat to host your web service (

http://www.jroller.com/**
gmazza/entry/ssl_for_web_****services<
http://www.jroller.com/gmazza/**entry/ssl_for_web_services<http://www.jroller.com/gmazza/entry/ssl_for_web_services>
),
I wouldn't rely on Endpoint.publish() for production, especially if
you're
using SSL.

For your dynamic client, as the link above mentions, the certs will
need
to be in the "cacerts" file used by the JRE that is running the dynamic
client--or another truststore file that you configure--the browser is
irrelevant as it's not being used there.

HTH,
Glen


On 06/25/2012 07:46 AM, Himanshu Gupta wrote:

  Hello Experts,

Quite new to CXF, having a usecase where I need to expose our existing
services as webservices. App is a standalone server, so am using

embedded

jetty with https. Everything works fine, except that when I hit the

server
with the wsdl url through a browser (any browser), I get
"javax.net.ssl.****SSLHandshakeException: no cipher suites in
common".

This could be reproduced if you just run the wsdl_first_https server

and

hit the url 
https://localhost:9001/****SoapContext/SoapPort?wsdl<https://localhost:9001/**SoapContext/SoapPort?wsdl>

https://localhost:9001/**SoapContext/SoapPort?wsdl<https://localhost:9001/SoapContext/SoapPort?wsdl>

.
Please help

escape this problem.

Also the client in the wsdl_first_https works. But if I try to use the
Dynamic Client (thats a requirement), it fails as well, as it could
not
find the wsdl. The Dynamic client looks somthing like below :


  JaxWsDynamicClientFactory dcf = JaxWsDynamicClientFactory.**
newInstance();
         Client client = dcf.createClient("
https://localhost:443/****someservice/2.0?wsdl<https://localhost:443/**someservice/2.0?wsdl>
<

https://localhost:443/**someservice/2.0?wsdl<https://localhost:443/someservice/2.0?wsdl>

<https://**localhost/**someservice/2.0?wsdl<

https://localhost/someservice/**2.0?wsdl<https://localhost/someservice/2.0?wsdl>

**>

");
         Object[] res = client.invoke(jnew
QName("http://someNameSpace/<**h**ttp://somenamespace/<

http://somenamespace/>

",

"getSomeIdentifier"), new Integer(1));

PS : I have already tried adding the certs to the browser.

Thanks in Advance,


  --

Glen Mazza
Talend Community Coders
coders.talend.com
blog: www.jroller.com/gmazza

--
Himanshu Gupta.

--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

--
Glen Mazza
Talend Community Coders
coders.talend.com
blog: www.jroller.com/gmazza



--
Glen Mazza
Talend Community Coders
coders.talend.com
blog: www.jroller.com/gmazza

Re: wsdl_first_https

Reply via email to