You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Fred Dushin (JIRA)" <ji...@apache.org> on 2009/08/04 20:26:15 UTC
[jira] Updated: (CXF-2380) Cannot use custom client TLS settings
when creating javax.xml.ws.Service from "https://...?wsdl" URL when WSDL
contains https imports
[ https://issues.apache.org/jira/browse/CXF-2380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fred Dushin updated CXF-2380:
-----------------------------
Attachment: CXF-2380.tar.gz
Test case for CXF-2380.
Instructions:
1. Unpack, cd in CXF-2380
2. mvn -Pserver &
3. mvn -Pclient
> Cannot use custom client TLS settings when creating javax.xml.ws.Service from "https://...?wsdl" URL when WSDL contains https imports
> -------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CXF-2380
> URL: https://issues.apache.org/jira/browse/CXF-2380
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
> Affects Versions: 2.2.3
> Reporter: Fred Dushin
> Attachments: CXF-2380.tar.gz
>
>
> (See enclosed test case, based on WSDL-first HTTPS sample)
> I have a CXF client and server. The server listens on https and publishes its WSDL at "https://...?wsdl".
> The scenario is also such that the WSDL published at this address has a wsdl:import, also with an https:// address, as in:
> <?xml version='1.0' encoding='UTF-8'?><wsdl:definitions ...>
> <wsdl:import location="https://localhost:9001/demo/secure?wsdl=Greeter.wsdl" namespace="http://apache.org/hello_world_soap_http">
> </wsdl:import>
> ...
> </wsdl:definitions>
> The client is designed so that:
> 1. It bootstraps the client proxy using the live "https://...?wsdl" URL at the service endpoint
> 2. The bus is programatically configured to use a custom resource resolver (see client source code in enclosed test case), so that custom key material (trusted certificates, in this case) is used when resolving the resource. I.e., we are NOT relying on the JVM's trust-store to establish trust with the server (or so is our desire).
> The client will fail to download all of the WSDL during the call to Service.create. The stacktrace is:
> javax.xml.ws.WebServiceException: org.apache.cxf.service.factory.ServiceConstructionException: Failed to create service.
> at org.apache.cxf.jaxws.ServiceImpl.<init>(ServiceImpl.java:149)
> at org.apache.cxf.jaxws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:65)
> at javax.xml.ws.Service.<init>(Service.java:36)
> at javax.xml.ws.Service.create(Service.java:116)
> at demo.hw_https.client.Client.call(Client.java:84)
> at demo.hw_https.client.Client.main(Client.java:76)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:592)
> at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:283)
> at java.lang.Thread.run(Thread.java:613)
> Caused by: org.apache.cxf.service.factory.ServiceConstructionException: Failed to create service.
> at org.apache.cxf.wsdl11.WSDLServiceFactory.<init>(WSDLServiceFactory.java:93)
> at org.apache.cxf.jaxws.ServiceImpl.initializePorts(ServiceImpl.java:204)
> at org.apache.cxf.jaxws.ServiceImpl.<init>(ServiceImpl.java:147)
> ... 11 more
> Caused by: javax.wsdl.WSDLException: WSDLException (at /wsdl:definitions/wsdl:import): faultCode=PARSER_ERROR: Problem parsing 'https://localhost:9001/demo/secure?wsdl=Greeter.wsdl'.: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
> at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(Unknown Source)
> at com.ibm.wsdl.xml.WSDLReaderImpl.parseImport(Unknown Source)
> at com.ibm.wsdl.xml.WSDLReaderImpl.parseDefinitions(Unknown Source)
> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
> at org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:210)
> at org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java:175)
> at org.apache.cxf.wsdl11.WSDLServiceFactory.<init>(WSDLServiceFactory.java:91)
> ... 13 more
> Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
> at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:150)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1584)
> at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:174)
> at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:168)
> at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:848)
> at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:106)
> at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:495)
> at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:433)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:877)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1089)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1116)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1100)
> at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:402)
> at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:166)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:960)
> at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:234)
> at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:973)
> at com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocVersion(XMLVersionDetector.java:184)
> at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:798)
> at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764)
> at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148)
> at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:250)
> at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:292)
> ... 24 more
> Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
> at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:221)
> at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:145)
> at sun.security.validator.Validator.validate(Validator.java:203)
> at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:172)
> at com.sun.net.ssl.internal.ssl.JsseX509TrustManager.checkServerTrusted(SSLContextImpl.java:320)
> at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:841)
> ... 42 more
> Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
> at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:236)
> at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:194)
> at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:216)
> ... 47 more
> Discussion:
> I believe what is happening here is that the com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL operation is not respecting the resource resolver that's been configured in CXF, when loading imported WSDLs, but that's just a guess. The reason I suspect this is that I have inserted printlns/breakpoints in the custom resource resolver, and we appear never to be calling resolve for the imported WSDL.
> Test Case:
> I'm submitting a test-case based on the wsdl-first https sample.
> To reproduce, use maven as per the usual instructions:
> mvn -Pserver
> mvn -Pclient
> Note that the client has been modified extensively in this sample. It will first make a plain http call to the service, to ensure that the server is at least running and nominally configured correctly. It will then attempt to connect over https, bootstrapping with the WSDL at the HTTPS service URL. It also has some code for adding a custom resource resolver, which is needed to set the TLS parameters on the client connection to the "https://...?wsdl" URL. (CXF is calling toString() the URL that's passed in to the Service.create operation, so that URL cannot carry the URLStreamHandler used to connect to the HTTPs URL.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.