cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Kulp (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CXF-2380) Cannot use custom client TLS settings when creating javax.xml.ws.Service from "https://...?wsdl" URL when WSDL contains https imports
Date Wed, 05 Aug 2009 17:41:15 GMT

    [ https://issues.apache.org/jira/browse/CXF-2380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739638#action_12739638
] 

Daniel Kulp commented on CXF-2380:
----------------------------------


Fred,

I can reproduce it here and am testing a fix.  

That said, you can probably work around it by changing your config.   If you change:

<http:conduit name="{http://apache.org/demos}SecureGreeterPort.http-conduit">

to:

<http:conduit name="https://localhost:9000/demo/secure.*">

It will probably work.   With recent versions of CXF, we allow the conduits to be configured
via URL wildcards and also have the wsdl loading and such use the conduits for https if possible.

 

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


Mime
View raw message