Discussion:
wsdl_first_https
(too old to reply)
Himanshu Gupta
2012-06-25 11:46:07 UTC
Permalink
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. 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/someservice/2.0?wsdl>
");
Object[] res = client.invoke(jnew
QName("http://someNameSpace/<http://somenamespace/>",
"getSomeIdentifier"), new Integer(1));

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

Thanks in Advance,
Glen Mazza
2012-06-25 12:51:31 UTC
Permalink
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), 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
Post by Himanshu Gupta
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. 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
JaxWsDynamicClientFactory dcf = JaxWsDynamicClientFactory.newInstance();
Client client = dcf.createClient("
https://localhost:443/someservice/2.0?wsdl<https://localhost/someservice/2.0?wsdl>
");
Object[] res = client.invoke(jnew
QName("http://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
2012-06-25 13:51:53 UTC
Permalink
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/ 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
");
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".", 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.
Post by Glen Mazza
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>),
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
Post by Himanshu Gupta
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>.
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
JaxWsDynamicClientFactory dcf = JaxWsDynamicClientFactory.**
newInstance();
Client client = dcf.createClient("
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>
**>
");
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
2012-06-25 13:57:22 UTC
Permalink
Post by Himanshu Gupta
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.
Post by Himanshu Gupta
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/ for
1. JaxWsDynamicClientFactory dcf = JaxWsDynamicClientFactory.newInstance();
2. Client client = dcf.createClient("
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".", 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.
Post by Glen Mazza
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>),
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
Post by Himanshu Gupta
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>.
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
JaxWsDynamicClientFactory dcf = JaxWsDynamicClientFactory.**
newInstance();
Client client = dcf.createClient("
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>
**>
");
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
Himanshu Gupta
2012-06-25 14:02:14 UTC
Permalink
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.
Post by Colm O hEigeartaigh
Post by Himanshu Gupta
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.
Post by Himanshu Gupta
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/ for
Post by Himanshu Gupta
1. JaxWsDynamicClientFactory dcf =
JaxWsDynamicClientFactory.newInstance();
Post by Himanshu Gupta
2. Client client = dcf.createClient("
https://localhost:9001/ApexCollateral/ing/services/wss/agreementDemo/2.0?wsdl
Post by Himanshu Gupta
");
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".", 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
Post by Himanshu Gupta
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.
Post by Glen Mazza
Personally, for SSL, I would recommend using a standalone servlet
container like Tomcat to host your web service (
http://www.jroller.com/**
Post by Himanshu Gupta
Post by Glen Mazza
gmazza/entry/ssl_for_web_**services<
http://www.jroller.com/gmazza/entry/ssl_for_web_services>),
Post by Himanshu Gupta
Post by Glen Mazza
I wouldn't rely on Endpoint.publish() for production, especially if
you're
Post by Himanshu Gupta
Post by Glen Mazza
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
Post by Himanshu Gupta
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
Post by Himanshu Gupta
Post by Glen Mazza
Post by Himanshu Gupta
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
Post by Himanshu Gupta
Post by Glen Mazza
Post by Himanshu Gupta
hit the url https://localhost:9001/**SoapContext/SoapPort?wsdl<
https://localhost:9001/SoapContext/SoapPort?wsdl>.
Post by Himanshu Gupta
Post by Glen Mazza
Post by Himanshu Gupta
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
JaxWsDynamicClientFactory dcf = JaxWsDynamicClientFactory.**
newInstance();
Client client = dcf.createClient("
https://localhost:443/**someservice/2.0?wsdl<
https://localhost:443/someservice/2.0?wsdl>
Post by Himanshu Gupta
Post by Glen Mazza
Post by Himanshu Gupta
<https://**localhost/someservice/2.0?wsdl<
https://localhost/someservice/2.0?wsdl>
Post by Himanshu Gupta
Post by Glen Mazza
Post by Himanshu Gupta
**>
");
Object[] res = client.invoke(jnew
QName("http://someNameSpace/<h**ttp://somenamespace/<
http://somenamespace/>
Post by Himanshu Gupta
Post by Glen Mazza
Post by Himanshu Gupta
",
"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
--
Himanshu Gupta.
Glen Mazza
2012-06-25 14:21:01 UTC
Permalink
Himanshu, did you clear your Firefox cache before trying again?

Glen
Post by Himanshu Gupta
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.
Post by Colm O hEigeartaigh
Post by Himanshu Gupta
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.
Post by Himanshu Gupta
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/ for
Post by Himanshu Gupta
1. JaxWsDynamicClientFactory dcf =
JaxWsDynamicClientFactory.newInstance();
Post by Himanshu Gupta
2. Client client = dcf.createClient("
https://localhost:9001/ApexCollateral/ing/services/wss/agreementDemo/2.0?wsdl
Post by Himanshu Gupta
");
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".", 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
Post by Himanshu Gupta
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.
Post by Glen Mazza
Personally, for SSL, I would recommend using a standalone servlet
container like Tomcat to host your web service (
http://www.jroller.com/**
Post by Himanshu Gupta
Post by Glen Mazza
gmazza/entry/ssl_for_web_**services<
http://www.jroller.com/gmazza/entry/ssl_for_web_services>),
Post by Himanshu Gupta
Post by Glen Mazza
I wouldn't rely on Endpoint.publish() for production, especially if
you're
Post by Himanshu Gupta
Post by Glen Mazza
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
Post by Himanshu Gupta
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
Post by Himanshu Gupta
Post by Glen Mazza
Post by Himanshu Gupta
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
Post by Himanshu Gupta
Post by Glen Mazza
Post by Himanshu Gupta
hit the url https://localhost:9001/**SoapContext/SoapPort?wsdl<
https://localhost:9001/SoapContext/SoapPort?wsdl>.
Post by Himanshu Gupta
Post by Glen Mazza
Post by Himanshu Gupta
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
JaxWsDynamicClientFactory dcf = JaxWsDynamicClientFactory.**
newInstance();
Client client = dcf.createClient("
https://localhost:443/**someservice/2.0?wsdl<
https://localhost:443/someservice/2.0?wsdl>
Post by Himanshu Gupta
Post by Glen Mazza
Post by Himanshu Gupta
<https://**localhost/someservice/2.0?wsdl<
https://localhost/someservice/2.0?wsdl>
Post by Himanshu Gupta
Post by Glen Mazza
Post by Himanshu Gupta
**>
");
Object[] res = client.invoke(jnew
QName("http://someNameSpace/<h**ttp://somenamespace/<
http://somenamespace/>
Post by Himanshu Gupta
Post by Glen Mazza
Post by Himanshu Gupta
",
"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
2012-06-25 14:42:27 UTC
Permalink
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).
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
[2] http://www.jroller.com/gmazza/entry/calling_rpc_encoded_web_services
Post by Himanshu Gupta
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.
Post by Colm O hEigeartaigh
Post by Himanshu Gupta
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.
Post by Himanshu Gupta
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/ for
Post by Himanshu Gupta
1. JaxWsDynamicClientFactory dcf =
JaxWsDynamicClientFactory.newInstance();
Post by Himanshu Gupta
2. Client client = dcf.createClient("
https://localhost:9001/ApexCollateral/ing/services/wss/agreementDemo/2.0?wsdl
Post by Himanshu Gupta
");
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".", 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
Post by Himanshu Gupta
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.
Post by Glen Mazza
Personally, for SSL, I would recommend using a standalone servlet
container like Tomcat to host your web service (
http://www.jroller.com/**
Post by Himanshu Gupta
Post by Glen Mazza
gmazza/entry/ssl_for_web_**services<
http://www.jroller.com/gmazza/entry/ssl_for_web_services>),
Post by Himanshu Gupta
Post by Glen Mazza
I wouldn't rely on Endpoint.publish() for production, especially if
you're
Post by Himanshu Gupta
Post by Glen Mazza
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
Post by Himanshu Gupta
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
Post by Himanshu Gupta
Post by Glen Mazza
Post by Himanshu Gupta
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
Post by Himanshu Gupta
Post by Glen Mazza
Post by Himanshu Gupta
hit the url https://localhost:9001/**SoapContext/SoapPort?wsdl<
https://localhost:9001/SoapContext/SoapPort?wsdl>.
Post by Himanshu Gupta
Post by Glen Mazza
Post by Himanshu Gupta
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
JaxWsDynamicClientFactory dcf = JaxWsDynamicClientFactory.**
newInstance();
Client client = dcf.createClient("
https://localhost:443/**someservice/2.0?wsdl<
https://localhost:443/someservice/2.0?wsdl>
Post by Himanshu Gupta
Post by Glen Mazza
Post by Himanshu Gupta
<https://**localhost/someservice/2.0?wsdl<
https://localhost/someservice/2.0?wsdl>
Post by Himanshu Gupta
Post by Glen Mazza
Post by Himanshu Gupta
**>
");
Object[] res = client.invoke(jnew
QName("http://someNameSpace/<h**ttp://somenamespace/<
http://somenamespace/>
Post by Himanshu Gupta
Post by Glen Mazza
Post by Himanshu Gupta
",
"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
Himanshu Gupta
2012-06-25 15:10:53 UTC
Permalink
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.
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>
Post by Himanshu Gupta
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.
Colm : I did add the certificates to for e.g. in the Firefox explicitly.
Post by Colm O hEigeartaigh
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.
Post by Himanshu Gupta
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
Post by Himanshu Gupta
1. JaxWsDynamicClientFactory dcf =
JaxWsDynamicClientFactory.**newInstance();
Post by Himanshu Gupta
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>
Post by Himanshu Gupta
");
3. configureSSLOnTheClient(**client);
4. Object[] res = client.invoke("**getAgreementDemoIdentifier", new
Integer(1));
Theoretically it should have worked, but it fails with an exception like
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
Post by Himanshu Gupta
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.
Personally, for SSL, I would recommend using a standalone servlet
Post by Glen Mazza
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.
Post by Glen Mazza
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
Hello Experts,
Post by Himanshu Gupta
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
Post by Glen Mazza
Post by Himanshu Gupta
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>
Post by Glen Mazza
Post by Himanshu Gupta
<
https://localhost:9001/**SoapContext/SoapPort?wsdl<https://localhost:9001/SoapContext/SoapPort?wsdl>
.
Please help
Post by Glen Mazza
Post by Himanshu Gupta
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
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<
Post by Glen Mazza
https://localhost/someservice/**2.0?wsdl<https://localhost/someservice/2.0?wsdl>
**>
Post by Glen Mazza
Post by Himanshu Gupta
");
Object[] res = client.invoke(jnew
QName("http://someNameSpace/<**h**ttp://somenamespace/<
http://somenamespace/>
",
Post by Glen Mazza
Post by Himanshu Gupta
"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
--
Himanshu Gupta.
Glen Mazza
2012-06-25 15:25:17 UTC
Permalink
Yes, Tomcat is embeddable:
www.jroller.com/gmazza/entry/junit_web_service_testing#testtc.

Glen
Post by Himanshu Gupta
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.
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>
Post by Himanshu Gupta
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.
Colm : I did add the certificates to for e.g. in the Firefox explicitly.
Post by Colm O hEigeartaigh
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.
Post by Himanshu Gupta
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
Post by Himanshu Gupta
1. JaxWsDynamicClientFactory dcf =
JaxWsDynamicClientFactory.**newInstance();
Post by Himanshu Gupta
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>
Post by Himanshu Gupta
");
3. configureSSLOnTheClient(**client);
4. Object[] res = client.invoke("**getAgreementDemoIdentifier", new
Integer(1));
Theoretically it should have worked, but it fails with an exception like
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
Post by Himanshu Gupta
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.
Personally, for SSL, I would recommend using a standalone servlet
Post by Glen Mazza
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.
Post by Glen Mazza
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
Hello Experts,
Post by Himanshu Gupta
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
Post by Glen Mazza
Post by Himanshu Gupta
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>
Post by Glen Mazza
Post by Himanshu Gupta
<
https://localhost:9001/**SoapContext/SoapPort?wsdl<https://localhost:9001/SoapContext/SoapPort?wsdl>
.
Please help
Post by Glen Mazza
Post by Himanshu Gupta
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
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<
Post by Glen Mazza
https://localhost/someservice/**2.0?wsdl<https://localhost/someservice/2.0?wsdl>
**>
Post by Glen Mazza
Post by Himanshu Gupta
");
Object[] res = client.invoke(jnew
QName("http://someNameSpace/<**h**ttp://somenamespace/<
http://somenamespace/>
",
Post by Glen Mazza
Post by Himanshu Gupta
"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
Himanshu Gupta
2012-06-25 15:54:03 UTC
Permalink
Hello Glen,
From your blog it looks like, the embedded Tomcat could be used with test,
and requires a war file or exploded war.

I have a spring based java stand alone server. I intend to use the web
server (embedded and in memory) in productive code. I cannot produce a war
like structure. I am looking for something like "JettyHTTPTransportFactory"
for Tomcat if possible.

I would need something like <httpj:engine-factory> and engine, for Tomcat.

PS : Is it not recommended to use embedded jetty in prod over ssl ?. That's
one of the key ("highlighted") document over the cxf website :(

Thanks,
Himanshu.
Yes, Tomcat is embeddable: www.jroller.com/gmazza/entry/**
junit_web_service_testing#**testtc<http://www.jroller.com/gmazza/entry/junit_web_service_testing#testtc>
.
Glen
Post by Himanshu Gupta
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.
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<htt**
p://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>
Post by Himanshu Gupta
).
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>
<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_**<http://www.jroller.com/gmazza/**entry/calling_rpc_encoded_web_**>
services<http://www.jroller.**com/gmazza/entry/calling_rpc_**
encoded_web_services<http://www.jroller.com/gmazza/entry/calling_rpc_encoded_web_services>
Hello Colm,
Post by Himanshu Gupta
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.
**
Colm : I did add the certificates to for e.g. in the Firefox explicitly.
Post by Colm O hEigeartaigh
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.
Post by Himanshu Gupta
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/>
<http://aruld.info/**programming-ssl-for-jetty-**based-cxf-services/<http://aruld.info/programming-ssl-for-jetty-based-cxf-services/>
Post by Himanshu Gupta
for
1. JaxWsDynamicClientFactory dcf =
JaxWsDynamicClientFactory.****newInstance();
2. Client client = dcf.createClient("
Post by Himanshu Gupta
https://localhost:9001/****ApexCollateral/ing/services/**<https://localhost:9001/**ApexCollateral/ing/services/**>
wss/agreementDemo/2.0?wsdl<htt**ps://localhost:9001/**
ApexCollateral/ing/services/**wss/agreementDemo/2.0?wsdl<https://localhost:9001/ApexCollateral/ing/services/wss/agreementDemo/2.0?wsdl>
");
Post by Himanshu Gupta
3. configureSSLOnTheClient(****client);
4. Object[] res = client.invoke("****getAgreementDemoIdentifier", new
Integer(1));
Theoretically it should have worked, but it fails with an exception like
Could not
resolve URL "https://localhost:9001/****someService/2.0?wsdl<https://localhost:9001/**someService/2.0?wsdl>
<https://**localhost:9001/someService/2.**0?wsdl<https://localhost:9001/someService/2.0?wsdl>
Post by Glen Mazza
".",
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
Post by Himanshu Gupta
approach I also validate auto code generation for clients, which would be
used eventually by the consumers (by exposed wsdls).
Please help,
Thanks,
Himanshu.
Personally, for SSL, I would recommend using a standalone servlet
Post by Glen Mazza
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>
<h**ttp://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.
Post by Glen Mazza
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
Hello Experts,
Post by Himanshu Gupta
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
Post by Glen Mazza
server
Post by Himanshu Gupta
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>
<http**s://localhost:9001/****SoapContext/SoapPort?wsdl<https://localhost:9001/**SoapContext/SoapPort?wsdl>
<
Post by Glen Mazza
Post by Himanshu Gupta
https://localhost:9001/****SoapContext/SoapPort?wsdl<https://localhost:9001/**SoapContext/SoapPort?wsdl>
<http**s://localhost:9001/**SoapContext/SoapPort?wsdl<https://localhost:9001/SoapContext/SoapPort?wsdl>
.
Please help
Post by Glen Mazza
escape this problem.
Post by Himanshu Gupta
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
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: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<
Post by Glen Mazza
https://localhost/someservice/****2.0?wsdl<https://localhost/someservice/**2.0?wsdl>
<https://localhost/**someservice/2.0?wsdl<https://localhost/someservice/2.0?wsdl>
**>
Post by Glen Mazza
");
Post by Himanshu Gupta
Object[] res = client.invoke(jnew
QName("http://someNameSpace/<****h**ttp://somenamespace/<
http://somenamespace/>
",
Post by Glen Mazza
"getSomeIdentifier"), new Integer(1));
Post by Himanshu Gupta
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
--
Himanshu Gupta.
Glen Mazza
2012-06-25 16:12:20 UTC
Permalink
Oh, no, CXF doesn't embed Tomcat in that manner, we use Jetty
behind-the-scenes for that only. Sorry if I misunderstood your question.

Regarding using embedded Jetty, that could just be me but I'm more
comfortable seeing secure solutions implemented behind a standalone
servlet container, JEE server or OSGi containers instead of relying on
Endpoint.publish(). However, using standalone containers may still
provide performance advantages, better logging, easier startup/shutdown,
etc., so you might choose to upgrade to them in the future anyway.

Glen
Post by Himanshu Gupta
Hello Glen,
From your blog it looks like, the embedded Tomcat could be used with test,
and requires a war file or exploded war.
I have a spring based java stand alone server. I intend to use the web
server (embedded and in memory) in productive code. I cannot produce a war
like structure. I am looking for something like "JettyHTTPTransportFactory"
for Tomcat if possible.
I would need something like<httpj:engine-factory> and engine, for Tomcat.
PS : Is it not recommended to use embedded jetty in prod over ssl ?. That's
one of the key ("highlighted") document over the cxf website :(
Thanks,
Himanshu.
Yes, Tomcat is embeddable: www.jroller.com/gmazza/entry/**
junit_web_service_testing#**testtc<http://www.jroller.com/gmazza/entry/junit_web_service_testing#testtc>
.
Glen
Post by Himanshu Gupta
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.
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<htt**
p://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>
Post by Himanshu Gupta
).
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>
<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_**<http://www.jroller.com/gmazza/**entry/calling_rpc_encoded_web_**>
services<http://www.jroller.**com/gmazza/entry/calling_rpc_**
encoded_web_services<http://www.jroller.com/gmazza/entry/calling_rpc_encoded_web_services>
Hello Colm,
Post by Himanshu Gupta
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.
**
Colm : I did add the certificates to for e.g. in the Firefox explicitly.
Post by Colm O hEigeartaigh
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.
Post by Himanshu Gupta
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/>
<http://aruld.info/**programming-ssl-for-jetty-**based-cxf-services/<http://aruld.info/programming-ssl-for-jetty-based-cxf-services/>
Post by Himanshu Gupta
for
1. JaxWsDynamicClientFactory dcf =
JaxWsDynamicClientFactory.****newInstance();
2. Client client = dcf.createClient("
Post by Himanshu Gupta
https://localhost:9001/****ApexCollateral/ing/services/**<https://localhost:9001/**ApexCollateral/ing/services/**>
wss/agreementDemo/2.0?wsdl<htt**ps://localhost:9001/**
ApexCollateral/ing/services/**wss/agreementDemo/2.0?wsdl<https://localhost:9001/ApexCollateral/ing/services/wss/agreementDemo/2.0?wsdl>
");
Post by Himanshu Gupta
3. configureSSLOnTheClient(****client);
4. Object[] res = client.invoke("****getAgreementDemoIdentifier", new
Integer(1));
Theoretically it should have worked, but it fails with an exception like
Could not
resolve URL "https://localhost:9001/****someService/2.0?wsdl<https://localhost:9001/**someService/2.0?wsdl>
<https://**localhost:9001/someService/2.**0?wsdl<https://localhost:9001/someService/2.0?wsdl>
Post by Glen Mazza
".",
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
Post by Himanshu Gupta
approach I also validate auto code generation for clients, which would be
used eventually by the consumers (by exposed wsdls).
Please help,
Thanks,
Himanshu.
Personally, for SSL, I would recommend using a standalone servlet
Post by Glen Mazza
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>
<h**ttp://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.
Post by Glen Mazza
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
Hello Experts,
Post by Himanshu Gupta
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
Post by Glen Mazza
server
Post by Himanshu Gupta
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>
<http**s://localhost:9001/****SoapContext/SoapPort?wsdl<https://localhost:9001/**SoapContext/SoapPort?wsdl>
<
Post by Glen Mazza
Post by Himanshu Gupta
https://localhost:9001/****SoapContext/SoapPort?wsdl<https://localhost:9001/**SoapContext/SoapPort?wsdl>
<http**s://localhost:9001/**SoapContext/SoapPort?wsdl<https://localhost:9001/SoapContext/SoapPort?wsdl>
.
Please help
Post by Glen Mazza
escape this problem.
Post by Himanshu Gupta
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
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: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<
Post by Glen Mazza
https://localhost/someservice/****2.0?wsdl<https://localhost/someservice/**2.0?wsdl>
<https://localhost/**someservice/2.0?wsdl<https://localhost/someservice/2.0?wsdl>
**>
Post by Glen Mazza
");
Post by Himanshu Gupta
Object[] res = client.invoke(jnew
QName("http://someNameSpace/<****h**ttp://somenamespace/<
http://somenamespace/>
",
Post by Glen Mazza
"getSomeIdentifier"), new Integer(1));
Post by Himanshu Gupta
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
--
Glen Mazza
Talend Community Coders
coders.talend.com
blog: www.jroller.com/gmazza
Himanshu Gupta
2012-06-26 07:51:16 UTC
Permalink
Hey Thanks Glen,

Thats exactly the plan. When we migrate from standalone java server to a
standard app server, we would no longer need this embedded jetty stuff.

Just to clarify, when you say, Endpoint.publish() is it a problem ?. We
use end point spring beans now (using <jaxws:endpoint>. its a spring app),
and I assume, this would still be the case when I use a standalone servlet
container. Am I wrong with this assumption ?

Thanks,
Post by Glen Mazza
Oh, no, CXF doesn't embed Tomcat in that manner, we use Jetty
behind-the-scenes for that only. Sorry if I misunderstood your question.
Regarding using embedded Jetty, that could just be me but I'm more
comfortable seeing secure solutions implemented behind a standalone servlet
container, JEE server or OSGi containers instead of relying on
Endpoint.publish(). However, using standalone containers may still provide
performance advantages, better logging, easier startup/shutdown, etc., so
you might choose to upgrade to them in the future anyway.
Glen
Post by Himanshu Gupta
Hello Glen,
From your blog it looks like, the embedded Tomcat could be used with test,
and requires a war file or exploded war.
I have a spring based java stand alone server. I intend to use the web
server (embedded and in memory) in productive code. I cannot produce a war
like structure. I am looking for something like
"JettyHTTPTransportFactory"
for Tomcat if possible.
I would need something like<httpj:engine-factory> and engine, for Tomcat.
PS : Is it not recommended to use embedded jetty in prod over ssl ?. That's
one of the key ("highlighted") document over the cxf website :(
Thanks,
Himanshu.
Yes, Tomcat is embeddable: www.jroller.com/gmazza/entry/****<http://www.jroller.com/gmazza/entry/**>
junit_web_service_testing#****testtc<http://www.jroller.com/**
gmazza/entry/junit_web_**service_testing#testtc<http://www.jroller.com/gmazza/entry/junit_web_service_testing#testtc>
.
Glen
Hello Glen,
Post by Himanshu Gupta
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.
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<**htt**
p://cxf.547215.n5.nabble.com/****template/NamlServlet.jtp?**<http://cxf.547215.n5.nabble.com/**template/NamlServlet.jtp?**>
macro=search_page&node=547216&****query=dynamic+client+ssl<htt**
p://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>
Post by Himanshu Gupta
).
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>
<http://**cxf.apache.org/docs/**dynamic-**clients.html<http://cxf.apache.org/docs/**dynamic-clients.html>
<http://**cxf.apache.org/docs/**dynamic-**clients.html<http://cxf.apache.org/docs/dynamic-**clients.html>
<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_**<http://www.jroller.com/gmazza/****entry/calling_rpc_encoded_**web_**>
<http://www.jroller.**com/gmazza/**entry/calling_**rpc_encoded_web_**<http://www.jroller.com/gmazza/**entry/calling_rpc_encoded_web_**>
services<http://www.jroller.****com/gmazza/entry/calling_rpc_****
encoded_web_services<http://**www.jroller.com/gmazza/entry/**
calling_rpc_encoded_web_**services<http://www.jroller.com/gmazza/entry/calling_rpc_encoded_web_services>
Hello Colm,
Post by Himanshu Gupta
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.
****
**
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
Post by Himanshu Gupta
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<
Post by Himanshu Gupta
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-******<http://aruld.info/programming-****ssl-for-jetty-based-cxf-****>
services/<http://aruld.info/**programming-**ssl-for-jetty-**
based-cxf-**services/<http://aruld.info/programming-**ssl-for-jetty-based-cxf-**services/>
<http://aruld.info/****programming-ssl-for-jetty-****
based-cxf-services/<http://aruld.info/**programming-ssl-for-jetty-**based-cxf-services/>
<http://**aruld.info/programming-ssl-**for-jetty-based-cxf-services/<http://aruld.info/programming-ssl-for-jetty-based-cxf-services/>
for
Post by Himanshu Gupta
1. JaxWsDynamicClientFactory dcf =
JaxWsDynamicClientFactory.******newInstance();
2. Client client = dcf.createClient("
Post by Himanshu Gupta
https://localhost:9001/******ApexCollateral/ing/services/**<https://localhost:9001/****ApexCollateral/ing/services/**>
**<https://localhost:9001/****ApexCollateral/ing/services/**<https://localhost:9001/**ApexCollateral/ing/services/**>
**>
wss/agreementDemo/2.0?wsdl<**htt**ps://localhost:9001/**
ApexCollateral/ing/services/****wss/agreementDemo/2.0?wsdl<htt**
ps://localhost:9001/**ApexCollateral/ing/services/**
wss/agreementDemo/2.0?wsdl<https://localhost:9001/ApexCollateral/ing/services/wss/agreementDemo/2.0?wsdl>
");
Post by Himanshu Gupta
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.******
Could not
resolve URL "https://localhost:9001/******someService/2.0?wsdl<https://localhost:9001/****someService/2.0?wsdl>
<https://**localhost:9001/**someService/**2.0?wsdl<https://localhost:9001/**someService/2.0?wsdl>
<https://**localhost:9001/**someService/2.**0?wsdl<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
Post by Himanshu Gupta
approach I also validate auto code generation for clients, which
would
be
used eventually by the consumers (by exposed wsdls).
Please help,
Thanks,
Himanshu.
Personally, for SSL, I would recommend using a standalone servlet
container like Tomcat to host your web service (
Post by Glen Mazza
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>
**<http://www.jroller.com/**gmazza/**entry/ssl_for_web_**services<http://www.jroller.com/gmazza/**entry/ssl_for_web_services>
<h**ttp://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<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
Post by Glen Mazza
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
Hello Experts,
Quite new to CXF, having a usecase where I need to expose our
Post by Himanshu Gupta
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
Post by Glen Mazza
Post by Himanshu Gupta
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>
<http**s://localhost:9001/******SoapContext/SoapPort?wsdl<https://localhost:9001/****SoapContext/SoapPort?wsdl>
<http**s://localhost:9001/******SoapContext/SoapPort?wsdl<http**
s://localhost:9001/****SoapContext/SoapPort?wsdl<https://localhost:9001/**SoapContext/SoapPort?wsdl>
<
Post by Glen Mazza
https://localhost:9001/******SoapContext/SoapPort?wsdl<https://localhost:9001/****SoapContext/SoapPort?wsdl>
Post by Himanshu Gupta
<http**s://localhost:9001/****SoapContext/SoapPort?wsdl<https://localhost:9001/**SoapContext/SoapPort?wsdl>
<http**s://localhost:9001/****SoapContext/SoapPort?wsdl<http**
s://localhost:9001/**SoapContext/SoapPort?wsdl<https://localhost:9001/SoapContext/SoapPort?wsdl>
.
Please help
escape this problem.
Post by Glen Mazza
Post by Himanshu Gupta
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
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: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: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: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>
Post by Glen Mazza
<https://**localhost/someservice/**2.0?**wsdl<https://localhost/someservice/**2.0?wsdl>
<https://localhost/****someservice/2.0?wsdl<https://localhost/**someservice/2.0?wsdl>
<https://**localhost/someservice/2.0?wsdl<https://localhost/someservice/2.0?wsdl>
**>
**>
");
Post by Glen Mazza
Post by Himanshu Gupta
Object[] res = client.invoke(jnew
QName("http://someNameSpace/<******h**ttp://somenamespace/<
http://somenamespace/>
",
"getSomeIdentifier"), new Integer(1));
Post by Glen Mazza
Post by Himanshu Gupta
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
--
Glen Mazza
Talend Community Coders
coders.talend.com
blog: www.jroller.com/gmazza
--
Himanshu Gupta.
Glen Mazza
2012-06-26 12:10:19 UTC
Permalink
When I said Endpoint.publish() I was speaking generically, meaning the
embedded Jetty, whether activated via Java API or via Spring (as you're
doing). For a standalone servlet container, you'd wrap your web service
in a WAR, and a special CXF servlet is used to host the endpoint
(http://www.jroller.com/gmazza/entry/web_service_tutorial#WFstep5).

With Tomcat your SSL configuration will be defined with Tomcat and the
web.xml (http://www.jroller.com/gmazza/entry/ssl_for_web_services), and
the jaxws:endpoint element (if it has anything left in it) having a
createdFromAPI value to "true" (I presently have a question on the CXF
IRC on the default value of createdFromAPI, as it's not given in your
documentation: http://cxf.apache.org/docs/jax-ws-configuration.html, but
I think that flag will need to be added when on Tomcat.)

Glen
Post by Himanshu Gupta
Hey Thanks Glen,
Thats exactly the plan. When we migrate from standalone java server to a
standard app server, we would no longer need this embedded jetty stuff.
Just to clarify, when you say, Endpoint.publish() is it a problem ?. We
use end point spring beans now (using<jaxws:endpoint>. its a spring app),
and I assume, this would still be the case when I use a standalone servlet
container. Am I wrong with this assumption ?
Thanks,
Post by Glen Mazza
Oh, no, CXF doesn't embed Tomcat in that manner, we use Jetty
behind-the-scenes for that only. Sorry if I misunderstood your question.
Regarding using embedded Jetty, that could just be me but I'm more
comfortable seeing secure solutions implemented behind a standalone servlet
container, JEE server or OSGi containers instead of relying on
Endpoint.publish(). However, using standalone containers may still provide
performance advantages, better logging, easier startup/shutdown, etc., so
you might choose to upgrade to them in the future anyway.
Glen
Post by Himanshu Gupta
Hello Glen,
From your blog it looks like, the embedded Tomcat could be used with test,
and requires a war file or exploded war.
I have a spring based java stand alone server. I intend to use the web
server (embedded and in memory) in productive code. I cannot produce a war
like structure. I am looking for something like
"JettyHTTPTransportFactory"
for Tomcat if possible.
I would need something like<httpj:engine-factory> and engine, for Tomcat.
PS : Is it not recommended to use embedded jetty in prod over ssl ?. That's
one of the key ("highlighted") document over the cxf website :(
Thanks,
Himanshu.
Yes, Tomcat is embeddable: www.jroller.com/gmazza/entry/****<http://www.jroller.com/gmazza/entry/**>
junit_web_service_testing#****testtc<http://www.jroller.com/**
gmazza/entry/junit_web_**service_testing#testtc<http://www.jroller.com/gmazza/entry/junit_web_service_testing#testtc>
.
Glen
Hello Glen,
Post by Himanshu Gupta
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.
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<**htt**
p://cxf.547215.n5.nabble.com/****template/NamlServlet.jtp?**<http://cxf.547215.n5.nabble.com/**template/NamlServlet.jtp?**>
macro=search_page&node=547216&****query=dynamic+client+ssl<htt**
p://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>
Post by Himanshu Gupta
).
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>
<http://**cxf.apache.org/docs/**dynamic-**clients.html<http://cxf.apache.org/docs/**dynamic-clients.html>
<http://**cxf.apache.org/docs/**dynamic-**clients.html<http://cxf.apache.org/docs/dynamic-**clients.html>
<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_**<http://www.jroller.com/gmazza/****entry/calling_rpc_encoded_**web_**>
<http://www.jroller.**com/gmazza/**entry/calling_**rpc_encoded_web_**<http://www.jroller.com/gmazza/**entry/calling_rpc_encoded_web_**>
services<http://www.jroller.****com/gmazza/entry/calling_rpc_****
encoded_web_services<http://**www.jroller.com/gmazza/entry/**
calling_rpc_encoded_web_**services<http://www.jroller.com/gmazza/entry/calling_rpc_encoded_web_services>
Hello Colm,
Post by Himanshu Gupta
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.
****
**
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
Post by Himanshu Gupta
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<
Post by Himanshu Gupta
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-******<http://aruld.info/programming-****ssl-for-jetty-based-cxf-****>
services/<http://aruld.info/**programming-**ssl-for-jetty-**
based-cxf-**services/<http://aruld.info/programming-**ssl-for-jetty-based-cxf-**services/>
<http://aruld.info/****programming-ssl-for-jetty-****
based-cxf-services/<http://aruld.info/**programming-ssl-for-jetty-**based-cxf-services/>
<http://**aruld.info/programming-ssl-**for-jetty-based-cxf-services/<http://aruld.info/programming-ssl-for-jetty-based-cxf-services/>
for
Post by Himanshu Gupta
1. JaxWsDynamicClientFactory dcf =
JaxWsDynamicClientFactory.******newInstance();
2. Client client = dcf.createClient("
Post by Himanshu Gupta
https://localhost:9001/******ApexCollateral/ing/services/**<https://localhost:9001/****ApexCollateral/ing/services/**>
**<https://localhost:9001/****ApexCollateral/ing/services/**<https://localhost:9001/**ApexCollateral/ing/services/**>
**>
wss/agreementDemo/2.0?wsdl<**htt**ps://localhost:9001/**
ApexCollateral/ing/services/****wss/agreementDemo/2.0?wsdl<htt**
ps://localhost:9001/**ApexCollateral/ing/services/**
wss/agreementDemo/2.0?wsdl<https://localhost:9001/ApexCollateral/ing/services/wss/agreementDemo/2.0?wsdl>
");
Post by Himanshu Gupta
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.******
Could not
resolve URL "https://localhost:9001/******someService/2.0?wsdl<https://localhost:9001/****someService/2.0?wsdl>
<https://**localhost:9001/**someService/**2.0?wsdl<https://localhost:9001/**someService/2.0?wsdl>
<https://**localhost:9001/**someService/2.**0?wsdl<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
Post by Himanshu Gupta
approach I also validate auto code generation for clients, which
would
be
used eventually by the consumers (by exposed wsdls).
Please help,
Thanks,
Himanshu.
Personally, for SSL, I would recommend using a standalone servlet
container like Tomcat to host your web service (
Post by Glen Mazza
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>
**<http://www.jroller.com/**gmazza/**entry/ssl_for_web_**services<http://www.jroller.com/gmazza/**entry/ssl_for_web_services>
<h**ttp://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<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
Post by Glen Mazza
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
Hello Experts,
Quite new to CXF, having a usecase where I need to expose our
Post by Himanshu Gupta
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
Post by Glen Mazza
Post by Himanshu Gupta
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>
<http**s://localhost:9001/******SoapContext/SoapPort?wsdl<https://localhost:9001/****SoapContext/SoapPort?wsdl>
<http**s://localhost:9001/******SoapContext/SoapPort?wsdl<http**
s://localhost:9001/****SoapContext/SoapPort?wsdl<https://localhost:9001/**SoapContext/SoapPort?wsdl>
<
Post by Glen Mazza
https://localhost:9001/******SoapContext/SoapPort?wsdl<https://localhost:9001/****SoapContext/SoapPort?wsdl>
Post by Himanshu Gupta
<http**s://localhost:9001/****SoapContext/SoapPort?wsdl<https://localhost:9001/**SoapContext/SoapPort?wsdl>
<http**s://localhost:9001/****SoapContext/SoapPort?wsdl<http**
s://localhost:9001/**SoapContext/SoapPort?wsdl<https://localhost:9001/SoapContext/SoapPort?wsdl>
.
Please help
escape this problem.
Post by Glen Mazza
Post by Himanshu Gupta
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
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: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: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: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>
Post by Glen Mazza
<https://**localhost/someservice/**2.0?**wsdl<https://localhost/someservice/**2.0?wsdl>
<https://localhost/****someservice/2.0?wsdl<https://localhost/**someservice/2.0?wsdl>
<https://**localhost/someservice/2.0?wsdl<https://localhost/someservice/2.0?wsdl>
**>
**>
");
Post by Glen Mazza
Post by Himanshu Gupta
Object[] res = client.invoke(jnew
QName("http://someNameSpace/<******h**ttp://somenamespace/<
http://somenamespace/>
",
"getSomeIdentifier"), new Integer(1));
Post by Glen Mazza
Post by Himanshu Gupta
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
--
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
Glen Mazza
2012-06-25 15:36:43 UTC
Permalink
Actually, per Colm's test (which I just verified, checking the WSDL at
https://localhost:9001/SoapContext/SoapPort?wsdl), just #1 alone should
be necessary for you to see the WSDL in the browser. I'm not sure how
#2 could possibly play a role with Firefox, unless Firefox is a Java app
(I don't believe it is, and the cacerts file means nothing to non-Java
apps.)

Glad to see things working well for you.

Glen
Post by Himanshu Gupta
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.
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>
Post by Himanshu Gupta
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.
Colm : I did add the certificates to for e.g. in the Firefox explicitly.
Post by Colm O hEigeartaigh
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.
Post by Himanshu Gupta
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
Post by Himanshu Gupta
1. JaxWsDynamicClientFactory dcf =
JaxWsDynamicClientFactory.**newInstance();
Post by Himanshu Gupta
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>
Post by Himanshu Gupta
");
3. configureSSLOnTheClient(**client);
4. Object[] res = client.invoke("**getAgreementDemoIdentifier", new
Integer(1));
Theoretically it should have worked, but it fails with an exception like
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
Post by Himanshu Gupta
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.
Personally, for SSL, I would recommend using a standalone servlet
Post by Glen Mazza
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.
Post by Glen Mazza
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
Hello Experts,
Post by Himanshu Gupta
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
Post by Glen Mazza
Post by Himanshu Gupta
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>
Post by Glen Mazza
Post by Himanshu Gupta
<
https://localhost:9001/**SoapContext/SoapPort?wsdl<https://localhost:9001/SoapContext/SoapPort?wsdl>
.
Please help
Post by Glen Mazza
Post by Himanshu Gupta
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
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<
Post by Glen Mazza
https://localhost/someservice/**2.0?wsdl<https://localhost/someservice/2.0?wsdl>
**>
Post by Glen Mazza
Post by Himanshu Gupta
");
Object[] res = client.invoke(jnew
QName("http://someNameSpace/<**h**ttp://somenamespace/<
http://somenamespace/>
",
Post by Glen Mazza
Post by Himanshu Gupta
"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
Colm O hEigeartaigh
2012-06-25 13:01:39 UTC
Permalink
Hi,

The reason you are getting the error "no cipher suites in common" when you
try to view the service wsdl of the wsdl_first_https sample is that the
service requires client authentication:

<sec:clientAuthentication want="true" required="true"/>

In other words, the https client must supply a (trusted) certificate in the
TLS handshake. As the browser does not supply a certificate you see the
error.

Colm.
Post by Himanshu Gupta
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. 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
JaxWsDynamicClientFactory dcf = JaxWsDynamicClientFactory.newInstance();
Client client = dcf.createClient("
https://localhost:443/someservice/2.0?wsdl<
https://localhost/someservice/2.0?wsdl>
");
Object[] res = client.invoke(jnew
QName("http://someNameSpace/<http://somenamespace/>",
"getSomeIdentifier"), new Integer(1));
PS : I have already tried adding the certs to the browser.
Thanks in Advance,
--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com
anshuiitk
2012-06-25 09:42:56 UTC
Permalink
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, 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. 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");
Object[] res = client.invoke(jnew QName("http://someNameSpace/",
"getSomeIdentifier"), new Integer(1));


Thanks in Advance,


--
View this message in context: http://cxf.547215.n5.nabble.com/wsdl-first-https-tp5710197.html
Sent from the cxf-user mailing list archive at Nabble.com.
Continue reading on narkive:
Loading...