Hello Glen, Thanks for the quick response. I am using scenario 2.
With Scenario 2 and 1. not using "<sec:clientAuthentication want="true" required="true"/>" 2. importing the server sertificate on the JDK default keystore "cacerts" I could see the wsdl in the web browser. The client in the sample also works well. Also the Dynamic client also works, because it uses the default keystore (you cannot change it for dynamic clients). Everyone's Happy, but this means any one who needs to see the wsdl on the browser would need to do 2 (i.e. import server cert on the jre default keystore) :(( ... Problem seems to be solved, but any Insights (explanations) would be helpful. PS : Glen, to your previous question, we can not use standalone tomcat, as we have a standalone java server, and we need an embedded in memory solution. please let me know, if this could be done using tomcat just like jetty. Thanks, Himanshu. On Mon, Jun 25, 2012 at 4:42 PM, Glen Mazza <[email protected]> wrote: > Himanshu, of the wsdl_first_https sample, which of the four scenarios are > you running--per that sample's README, scenarios 1 and 3 are supposed to > fail due to lack of client credentials, while scenarios 2 and 4 should > work. Also, is the problem with the running of the sample or just you > viewing it from the browser? > > The blog entry you're referencing is from 2008 and covers the > long-obsoleted CXF 2.1 (our lowest supported version is now 2.4), I would > be surprised if that code still worked. I'm not much familiar with the > Dynamic Client (I don't hear much about it today), whether it can/should > work with HTTPS (the docs for it do not give that indication[1]), hopefully > someone else can help you here or maybe the Nabble forums can help ( > http://cxf.547215.n5.nabble.**com/template/NamlServlet.jtp?** > macro=search_page&node=547216&**query=dynamic+client+ssl<http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=search_page&node=547216&query=dynamic+client+ssl>). > You might be better off with the more standard JAX-WS Dispatch method[2] > if you can't use stub-based calls. > > Glen > > [1] > http://cxf.apache.org/docs/**dynamic-clients.html<http://cxf.apache.org/docs/dynamic-clients.html> > [2] http://www.jroller.com/gmazza/**entry/calling_rpc_encoded_web_** > services<http://www.jroller.com/gmazza/entry/calling_rpc_encoded_web_services> > > > On 06/25/2012 10:02 AM, Himanshu Gupta wrote: > >> Hello Colm, >> >> In the sample wsdl_first_https, I removed line<sec:clientAuthentication >> want="true" required="true"/> from the server configuration. The Client >> in >> the example works well. But the Firefox fails, and still gives error >> "javax.net.ssl.**SSLHandshakeException: no cipher suites in common" on >> the >> server. >> >> Please let me know, If you want me to try something specific. >> >> Sorry just looking for an appropriate solution :( >> >> Thanks, >> Himanshu. >> >> >> On Mon, Jun 25, 2012 at 3:57 PM, Colm O hEigeartaigh<coheigea@apache.** >> org <[email protected]>>wrote: >> >> Colm : I did add the certificates to for e.g. in the Firefox explicitly. >>>> >>> Yes, you added the certificates so that the browser trusted the service >>> endpoint. However, as I explained in my previous mail, the service >>> endpoint >>> requires that the client presents its own certificate + private key for >>> client authentication, hence the failure. >>> >>> Colm. >>> >>> On Mon, Jun 25, 2012 at 2:51 PM, Himanshu Gupta<[email protected] >>> >>>> wrote: >>>> Hello Guys, >>>> >>>> Colm : I did add the certificates to for e.g. in the Firefox explicitly. >>>> >>>> Following >>>> >>> http://aruld.info/programming-**ssl-for-jetty-based-cxf-**services/<http://aruld.info/programming-ssl-for-jetty-based-cxf-services/>for >>> >>>> my Dynamic Client, I try to do somthing like below : >>>> >>>> 1. JaxWsDynamicClientFactory dcf = >>>> >>> JaxWsDynamicClientFactory.**newInstance(); >>> >>>> 2. Client client = dcf.createClient(" >>>> >>>> https://localhost:9001/**ApexCollateral/ing/services/** >>> wss/agreementDemo/2.0?wsdl<https://localhost:9001/ApexCollateral/ing/services/wss/agreementDemo/2.0?wsdl> >>> >>>> "); >>>> 3. configureSSLOnTheClient(**client); >>>> 4. Object[] res = client.invoke("**getAgreementDemoIdentifier", new >>>> Integer(1)); >>>> >>>> Theoretically it should have worked, but it fails with an exception like >>>> "org.apache.cxf.service.**factory.**ServiceConstructionException: >>>> Could not >>>> resolve URL >>>> "https://localhost:9001/**someService/2.0?wsdl<https://localhost:9001/someService/2.0?wsdl>".", >>>> while >>>> excetuing *line number 2 (*logs attached*) *that is even before line 3 >>>> where I could setup the truststore, manually. >>>> >>>> I really want to use the Dynamic Client approach in the test cases to >>>> >>> test >>> >>>> my web services. I assume, along with the testing services, with this >>>> approach I also validate auto code generation for clients, which would >>>> be >>>> used eventually by the consumers (by exposed wsdls). >>>> >>>> Please help, >>>> >>>> Thanks, >>>> Himanshu. >>>> >>>> >>>> On Mon, Jun 25, 2012 at 2:51 PM, Glen Mazza<[email protected]> wrote: >>>> >>>> Personally, for SSL, I would recommend using a standalone servlet >>>>> container like Tomcat to host your web service ( >>>>> >>>> http://www.jroller.com/** >>> >>>> gmazza/entry/ssl_for_web_****services< >>>>> >>>> http://www.jroller.com/gmazza/**entry/ssl_for_web_services<http://www.jroller.com/gmazza/entry/ssl_for_web_services> >>> >), >>> >>>> I wouldn't rely on Endpoint.publish() for production, especially if >>>>> >>>> you're >>> >>>> using SSL. >>>>> >>>>> For your dynamic client, as the link above mentions, the certs will >>>>> need >>>>> to be in the "cacerts" file used by the JRE that is running the dynamic >>>>> client--or another truststore file that you configure--the browser is >>>>> irrelevant as it's not being used there. >>>>> >>>>> HTH, >>>>> Glen >>>>> >>>>> >>>>> On 06/25/2012 07:46 AM, Himanshu Gupta wrote: >>>>> >>>>> Hello Experts, >>>>>> >>>>>> Quite new to CXF, having a usecase where I need to expose our existing >>>>>> services as webservices. App is a standalone server, so am using >>>>>> >>>>> embedded >>> >>>> jetty with https. Everything works fine, except that when I hit the >>>>>> server >>>>>> with the wsdl url through a browser (any browser), I get >>>>>> "javax.net.ssl.****SSLHandshakeException: no cipher suites in >>>>>> common". >>>>>> >>>>>> This could be reproduced if you just run the wsdl_first_https server >>>>>> >>>>> and >>> >>>> hit the url >>>> https://localhost:9001/****SoapContext/SoapPort?wsdl<https://localhost:9001/**SoapContext/SoapPort?wsdl> >>>>>> < >>>>>> >>>>> https://localhost:9001/**SoapContext/SoapPort?wsdl<https://localhost:9001/SoapContext/SoapPort?wsdl> >>> >. >>> >>>> Please help >>>>>> escape this problem. >>>>>> >>>>>> Also the client in the wsdl_first_https works. But if I try to use the >>>>>> Dynamic Client (thats a requirement), it fails as well, as it could >>>>>> not >>>>>> find the wsdl. The Dynamic client looks somthing like below : >>>>>> >>>>>> >>>>>> JaxWsDynamicClientFactory dcf = JaxWsDynamicClientFactory.** >>>>>> newInstance(); >>>>>> Client client = dcf.createClient(" >>>>>> https://localhost:443/****someservice/2.0?wsdl<https://localhost:443/**someservice/2.0?wsdl> >>>>>> < >>>>>> >>>>> https://localhost:443/**someservice/2.0?wsdl<https://localhost:443/someservice/2.0?wsdl> >>> > >>> >>>> <https://**localhost/**someservice/2.0?wsdl< >>>>>> >>>>> https://localhost/someservice/**2.0?wsdl<https://localhost/someservice/2.0?wsdl> >>> > >>> >>>> **> >>>>>> >>>>>> "); >>>>>> Object[] res = client.invoke(jnew >>>>>> QName("http://someNameSpace/<**h**ttp://somenamespace/< >>>>>> >>>>> http://somenamespace/> >>> >>>> ", >>>>>>> >>>>>> "getSomeIdentifier"), new Integer(1)); >>>>>> >>>>>> PS : I have already tried adding the certs to the browser. >>>>>> >>>>>> Thanks in Advance, >>>>>> >>>>>> >>>>>> -- >>>>> Glen Mazza >>>>> Talend Community Coders >>>>> coders.talend.com >>>>> blog: www.jroller.com/gmazza >>>>> >>>>> >>>>> >>>> -- >>>> Himanshu Gupta. >>>> >>>> >>> >>> -- >>> Colm O hEigeartaigh >>> >>> Talend Community Coder >>> http://coders.talend.com >>> >>> >> >> > > -- > Glen Mazza > Talend Community Coders > coders.talend.com > blog: www.jroller.com/gmazza > > -- Himanshu Gupta.
