I think it's a config issue. The client configurations for the conduits are
based on endpoint name, not URL. Since the endpoint name isn't available as
part of grabbing the WSDL, it's not picking it up. If you change the xml
configuration from:
<http:conduit name="{http://apache.org/hello_world_soap_http}SoapPort.http-
conduit">
to something like:
<http:conduit name="https://localhost:9001/.*";>
or similar (use your host name if you aren't using localhost), it may work as
it will grab the configuration based on the URL instead of the endpoint name.
BTW: if that works, submit a patch. :-)
Dan
On Wed August 12 2009 2:27:30 pm Stephen Langella wrote:
> Eamon,
>
> I tried you suggestion, but had the same results, any other ideas?
> Perhaps this is a bug?
>
> --Steve
>
> Stephen Langella
> Co-Director
> Software Research Institute
> Center for IT Innovations in Healthcare
> Ohio State University
>
> Senior Researcher
> Department of Biomedical Informatics
> Ohio State University
>
> Office: (614) 293-9534
> Lab: (614) 292-8420
> [email protected]
>
> > From: Eamonn Dwyer <[email protected]>
> > Reply-To: <[email protected]>
> > Date: Wed, 12 Aug 2009 11:23:31 +0100
> > To: <[email protected]>
> > Subject: RE: HTTPS
> >
> >
> > Hi Stephen
> > I wonder would it work any better if you changed the trustManages and
> > keyStores to use the "resource=" prefix rather than the "file=" prefix.
> > The "resource=" prefix tells the code to load the certificate from the
> > classpath rather than the relative path. For example
> >
> > <sec:trustManagers>
> > <sec:keyStore type="JKS" password="password"
> > resource="certs/truststore.jks"/>
> > </sec:trustManagers>
> > <sec:keyManagers keyPassword="password">
> > <sec:keyStore type="JKS" password="password"
> > resource="certs/wibble.jks"/>
> > </sec:keyManagers>
> >
> >
> > Regards
> > Eamonn
> >
> >> From: [email protected]
> >> To: [email protected]
> >> Subject: HTTPS
> >> Date: Tue, 11 Aug 2009 22:42:15 -0400
> >>
> >> I was playing around with the WSDL First HTTPS sample distributed with
> >> apache 2.2.3. I got it working out of the box as one might have
> >> expected, I did however run into a problem when changing around the
> >> client to use the remote WSDL published by the service instead of the
> >> local file. When I do this I get the following exception:
> >>
> >> Caused by: javax.wsdl.WSDLException: WSDLException:
> >> faultCode=PARSER_ERROR: Problem parsing
> >> 'https://llanowar:9001/HelloWorldService?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.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)
> >> ... 9 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:
> >> 951)
> >> 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)
> >> ... 15 more
> >>
> >> It seems that the code that obtains the remote WSDL (WSDLReaderImpl)
> >> is not using the trust manager configuration set in the spring
> >> configuration file (WibbleClient.xml). I can get to work if I set
> >> the ³javax.net.ssl.trustStore³ system property to the trust store I
> >> configured in WibbleClient.xml, however this seems redundant and I
> >> would think that the underlying client code would use a single point
> >> of configuration, am I missing something?, is this intentional?, or is
> >> this a bug? Thanks in advance.
> >>
> >> --Steve
> >>
> >> Stephen Langella
> >> Co-Founder
> >> Inventrio, LLC
> >> www.inventrio.com
> >>
> >> [email protected]
> >
> > _________________________________________________________________
> > See all the ways you can stay connected to friends and family
> > http://www.microsoft.com/windows/windowslive/default.aspx
--
Daniel Kulp
[email protected]
http://www.dankulp.com/blog
