Getting WS WSDL to give correct name in the response

Hi,

My situation is I have a cluster where I'm trying to get Web Services working. The cluster is hosted in a government data centre. Their policy is to have two NIC's on each box - one for RDP and one for everything else. THe problem is that the first one which is accessible for RDP is the primary, and it's inaccessible everywhere else. For example, if I make a request to https://servername.correctdomain.gc.ca/cws/Authentication.svc?wsdl, I will get a WSDL like this:

<wsdl:definitions name="Authentication" targetNamespace="urn:Core.service.livelink.opentext.com">

<wsp:Policy wsu:Id="BasicHttpBinding_Authentication1_policy">

</wsp:Policy>

<wsdl:types>

<xsd:schema targetNamespace="urn:Core.service.livelink.opentext.com/Imports">

<xsd:import schemaLocation="https://servername.incorrectdomain.gc.ca/cws/Authentication.svc?xsd=xsd0" namespace="urn:Core.service.livelink.opentext.com"/>

<xsd:import schemaLocation=""https://servername.incorrectdomain.gc.ca/cws/Authentication.svc?xsd=xsd1" namespace="urn:api.ecm.opentext.com"/></xsd:schema></wsdl:types>

I saw a response from Appu on a related issue here:

https://knowledge.opentext.com/knowledge/cs.dll?func=ll&objId=36720137&objAction=viewincontainer&ShowReplyEntry=36723137#forum_topic_36723137

I tried implementing the prefix but got several exceptions when I tried to do so.

I also saw this earlier post I did, where it was suggested I enable SSL endpoints and some https attributes which I did

https://knowledge.opentext.com/knowledge/cs.dll?func=ll&objId=66144124&objAction=viewincontainer&ShowReplyEntry=66147456#forum_topic_66147456

The exact instructions were in the generated web.config, mainly this:

I guess I have two problems:

1) How to get returned WSDL to give the correct NIC's FQDN instead of the unroutable one, and

2) How to properly support https with Web Services besides the obvious which are commented in the default web.config.

Thanks in advance

Find more posts tagged with

Comments

AKropp

Hi Hugh,

I did a little hunting and this kind of config issue seems to be plastered all over half the internet sites dealing in IIS. Mostly like candidate I could find is an element you can add to the behavior called useRequestHeadersForMetadataAddress. There’s a post with example syntax here – seems easy enough to try it (disclaimer: I haven’t)http://granitestatehacker.kataire.com/2012/04/url-for-wsdl-coming-back-with-wrong.html. Presumably it makes the generated WSDL use whatever is specified in the client request headers to build out those portions (didn’t have much luck finding an explanatory MSDN link). Worth a shot.

On the SSL/TLS side of things I’ve never had to do anything but simply uncomment the sections already included in the web.config and make sure IIS is set up with the cert for it. Both my test systems are available via HTTP and HTTPS without any further tinkering.

I’d be interested to know if that web.config setting in the first paragraph does the trick. We could whip up a quick knowledgebase article if it does as I’m sure others have been or will be in that boat.

From: eLink Entry: Content Web Services Forum <otdncontentwebservices971forum@elinkkc.opentext.com>
Sent: Tuesday, September 4, 2018 1:09 PM
To: eLink Recipient <devnull@elinkkc.opentext.com>
Subject: Getting WS WSDL to give correct name in the response

Getting WS WSDL to give correct name in the response

Posted byhugh@hferguson.ca (Ferguson, Hugh) On 09/04/2018 01:06 PM

Hi,

My situation is I have a cluster where I'm trying to get Web Services working. The cluster is hosted in a government data centre. Their policy is to have two NIC's on each box - one for RDP and one for everything else. THe problem is that the first one which is accessible for RDP is the primary, and it's inaccessible everywhere else. For example, if I make a request tohttps://servername.correctdomain.gc.ca/cws/Authentication.svc?wsdl, I will get a WSDL like this:

<wsdl:definitions name="Authentication" targetNamespace="urn:Core.service.livelink.opentext.com">

<wsp:Policy wsu:Id="BasicHttpBinding_Authentication1_policy">

</wsp:Policy>

<wsdl:types>

<xsd:schema targetNamespace="urn:Core.service.livelink.opentext.com/Imports">

<xsd:import schemaLocation="https://servername.incorrectdomain.gc.ca/cws/Authentication.svc?xsd=xsd0" namespace="urn:Core.service.livelink.opentext.com"/>

<xsd:import schemaLocation=""https://servername.incorrectdomain.gc.ca/cws/Authentication.svc?xsd=xsd1" namespace="urn:api.ecm.opentext.com"/></xsd:schema></wsdl:types>

I saw a response from Appu on a related issue here:

https://knowledge.opentext.com/knowledge/cs.dll?func=ll&objId=36720137&objAction=viewincontainer&ShowReplyEntry=36723137#forum_topic_36723137

I tried implementing the prefix but got several exceptions when I tried to do so.

I also saw this earlier post I did, where it was suggested I enable SSL endpoints and some https attributes which I did

https://knowledge.opentext.com/knowledge/cs.dll?func=ll&objId=66144124&objAction=viewincontainer&ShowReplyEntry=66147456#forum_topic_66147456

The exact instructions were in the generated web.config, mainly this:

I guess I have two problems:

1) How to get returned WSDL to give the correct NIC's FQDN instead of the unroutable one, and

2) How to properly support https with Web Services besides the obvious which are commented in the default web.config.

Thanks in advance

[To post a comment, use the normal reply function]
Forum:	Content Web Services Forum
Content Server:	My Support

Benjamin Shapiro

<!DOCTYPE html>

One solution I've seen historically was to save the WSDL file locally, do a search/replace on the server name(s), then load that back in.

That seems unsatisfying, but it worked.

Cheers,

Ben

HFCDev

Hi Ben,

If I was using my own client app, that's exactly what I'd do (and what I did do in the first KC post I highlighted). This is to get Kofax's CS release script to work.

-Hugh

HFCDev

Quoted Alex Kropp on 09/04/2018 02:15 PM:

Hi Hugh,

I did a little hunting and this kind of config issue seems to be plastered all over half the internet sites dealing in IIS. Mostly like candidate I could find is an element you can add to the behavior called useRequestHeadersForMetadataAddress. There’s a post with example syntax here – seems easy enough to try it (disclaimer: I haven’t) http://granitestatehacker.kataire.com/2012/04/url-for-wsdl-coming-back-with-wrong.html. Presumably it makes the generated WSDL use whatever is specified in the client request headers to build out those portions (didn’t have much luck finding an explanatory MSDN link). Worth a shot.

That part did indeed work...

Quoted Alex Kropp on 09/04/2018 02:15 PM:

I'm not there yet with https, but I at least got the http request to work. Here is the stack trace from my test using https:

com.sun.xml.internal.ws.wsdl.parser.InaccessibleWSDLException: 2 counts of InaccessibleWSDLException.

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

I'm not sure what it's trying to follow for the certification path.

-Hugh

appuGmail

Hugh,

I have only done very few self signed https something tells me if the http and https sections are in the Web.Config of your IIS it wont jive

https://appukili.wordpress.com/2012/12/13/https-with-webservices-in-livelink/

I don't have any of the documents that was hosted in communities website . AK says it should work with http and https in the same web.Config I would

trust AK but in case another theory

Ciao,

..... appnair appunair( Livelink Rocks )

Well, if I called the wrongnumber, why did you answer the phone?
James Thurber, New Yorker cartoon caption, June 5, 1937

On Tue, Sep 4, 2018 at 1:20 PM, eLink Entry: Content Web Services Forum <otdncontentwebservices971forum@elinkkc.opentext.com> wrote:

RE Getting WS WSDL to give correct name in the response Posted byhugh@hferguson.ca (Ferguson, Hugh)On 09/04/2018 02:15 PM

Quoted Alex Kropp on 09/04/2018 02:15 PM:

Hi Hugh, I did a little hunting and this kind of config issue seems to be plastered all over half the internet sites dealing in IIS. Mostly like candidate I could find is an element you can add to the behavior called useRequestHeadersForMetadataAddress. There’s a post with example syntax here – seems easy enough to try it (disclaimer: I haven’t) http://granitestatehacker.kataire.com/2012/04/url-for-wsdl-coming-back-with-wrong.html. Presumably it makes the generated WSDL use whatever is specified in the client request headers to build out those portions (didn’t have much luck finding an explanatory MSDN link). Worth a shot.

That part did indeed work...

Quoted Alex Kropp on 09/04/2018 02:15 PM:

I'm not there yet with https, but I at least got the http request to work. Here is the stack trace from my test using https:

com.sun.xml.internal.ws.wsdl.parser.InaccessibleWSDLException: 2 counts of InaccessibleWSDLException.

I'm not sure what it's trying to follow for the certification path.

-Hugh

[To post a comment, use the normal reply function]
Topic:	Getting WS WSDL to give correct name in the response
Forum:	Content Web Services Forum
Content Server:	My Support

HFCDev

Well, I now know why I couldn't connect. The problem was that our environment is non-PRD and as such was given an internal cert to do SSL. Any java application would need to import the root cert into its certificate store.

https://confluence.atlassian.com/kb/unable-to-connect-to-ssl-services-due-to-pkix-path-building-failed-779355358.html

As my intentions were to get Kofax Capture going, I went back and tried using the Kofax set up screens and it did accept the https version of the URL.

-Hugh

AKropp

Glad the first tip worked out.

Hmm… might be a bit out of my depth on the SSL thing. Sounds to me like it might have to do what the certificate that IIS is using was issued to. If the cert path goes to a specific machine name, or one of the two DNS names explicitly then the client side might refuse to work if it’s resolving the some other name. Not applicable at all if it’s a wildcard cert, I don’t think. However I’m not an expert on this subject, only a crypto enthusiast.

Or maybe I’m over thinking it and the public cert for the server just needs to be imported into the client application’s keystore. The Java keytool is pretty ubiquitous and fairly well documented on how to go about that. I know I had to do those steps to make Cluster Management available via SSL by making the keystore, importing the cert and pointing CM at it. Not sure how KRS implements this (or if it does). In my case my cert is snake-oil and definitely not trustworthy by itself. More practically, I’ve seen some org’s that don’t use one of the major CAs as a trust underpinning have to do similar in that Cluster Management case. One Java client is as good as any other…

From: eLink Entry: Content Web Services Forum <otdncontentwebservices971forum@elinkkc.opentext.com>
Sent: Tuesday, September 4, 2018 2:20 PM
To: eLink Recipient <devnull@elinkkc.opentext.com>
Subject: RE Getting WS WSDL to give correct name in the response

RE Getting WS WSDL to give correct name in the response

Posted byhugh@hferguson.ca (Ferguson, Hugh) On 09/04/2018 02:15 PM

Quoted Alex Kropp on 09/04/2018 02:15 PM:

Hi Hugh,

That part did indeed work...

Quoted Alex Kropp on 09/04/2018 02:15 PM:

I'm not there yet with https, but I at least got the http request to work. Here is the stack trace from my test using https:

com.sun.xml.internal.ws.wsdl.parser.InaccessibleWSDLException: 2 counts of InaccessibleWSDLException.

I'm not sure what it's trying to follow for the certification path.

-Hugh

[To post a comment, use the normal reply function]
Topic:	Getting WS WSDL to give correct name in the response
Forum:	Content Web Services Forum
Content Server:	My Support