You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Stephen Langella <st...@inventrio.com> on 2009/08/12 04:42:15 UTC
HTTPS
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
Stephen.Langella@inventrio.com
Re: HTTPS
Posted by Daniel Kulp <dk...@apache.org>.
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
> Stephen.Langella@osumc.edu
>
> > From: Eamonn Dwyer <ea...@hotmail.com>
> > Reply-To: <us...@cxf.apache.org>
> > Date: Wed, 12 Aug 2009 11:23:31 +0100
> > To: <us...@cxf.apache.org>
> > 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: stephen.langella@inventrio.com
> >> To: users@cxf.apache.org
> >> 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
> >>
> >> Stephen.Langella@inventrio.com
> >
> > _________________________________________________________________
> > See all the ways you can stay connected to friends and family
> > http://www.microsoft.com/windows/windowslive/default.aspx
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: HTTPS
Posted by Stephen Langella <St...@osumc.edu>.
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
Stephen.Langella@osumc.edu
> From: Eamonn Dwyer <ea...@hotmail.com>
> Reply-To: <us...@cxf.apache.org>
> Date: Wed, 12 Aug 2009 11:23:31 +0100
> To: <us...@cxf.apache.org>
> 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: stephen.langella@inventrio.com
>> To: users@cxf.apache.org
>> 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
>>
>> Stephen.Langella@inventrio.com
>>
>>
>>
>>
>>
>>
>
> _________________________________________________________________
> See all the ways you can stay connected to friends and family
> http://www.microsoft.com/windows/windowslive/default.aspx
RE: HTTPS
Posted by Eamonn Dwyer <ea...@hotmail.com>.
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: stephen.langella@inventrio.com
> To: users@cxf.apache.org
> 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
>
> Stephen.Langella@inventrio.com
>
>
>
>
>
>
_________________________________________________________________
See all the ways you can stay connected to friends and family
http://www.microsoft.com/windows/windowslive/default.aspx