contacting secure webservice behind loadbalancer

[Esquerel]

Hello,

This is my first post, so i don't really now if i'm in the right group here.

We have 2 servers behind a load balancer, SSL offLoading is enabled on the
loadbalancer.
Both servers contain 2 identical webservices.
the first can be contacted trough http.
the other through https.

When in VS.NET i add a WebRefence to the secured webservice
(https://website/webservice/webservice.asmx) I get the following
Error message:

--
Unable to download following files from .
http://website:81/webservice/webservice.asmx?wsdl
Do you want to skip these files and continue?
--

When i contact the first webservice, everything works ok.

When i set the the webreference to Dynamic URL behavoir and
change the webreference URL to the secured webservice the following
exception
occures:

--
"System.Web.Services.Protocols.SoapHeaderException: Server unavailable,
please try later --->
System.ApplicationException: An error occured processing an outgoing fault
response\n
--- End of inner exception stack trace ---"
--

Does anyone now how to fix this problem?
Is it true that to problem lies in the loadbalancer, that the SSL offloading
is causing the problem
cause SSL encryption occures on the loadbalancer and not on the 2 server?

Thanks in advance,

Regards,

Tyhrstan van den Berg

 

[Steven Cheng[MSFT]]

Hello Tyhrstan,

From your description, you have an web service applications which has been
deployed as secured(https/ssl) and non-secured on two webservers work as
loading balance mode. However, when you try consuming the secured
webservice, you always get exception, correct?

Based on my experience, for consuming https/ssl secured ASP.NET webservice,
you need to first create the webservice proxy through non-secured endpoint
(http:// url), and then manually change the address to https one.

Also, for https/ssl secured webservice, so far I only ever met some
problems about the validation of server-side certificate. Because for
HTTPS/SSL, the client-side will always try validating the server
certificate of the SSL server-side, if the certificate is not recognized as
a trusted one, then, it will raise exception (for webservice scenario since
it is non-interactive). Here is a web article mentioned this:

http://weblogs.asp.net/jan/archive/2003/12/04/41154.aspx

I suggest you try consuming the https/ssl secured webservice without using
load balance mode to see whether you can correctly consume it. If still
not, the problem should be related to the ssl/https channel intialization.
If it works, the problem should be caused by the load balance mode.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead



==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.



Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.

==================================================



This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Esquerel]

Hello Steven,

We have tried your first solution to the problem but still the same error.

We suspect it has something to do with the discovery file because when
we load the url https://website/webservice/webservice.asmx?disco
it shows the following urls in the discovery file.

------------
<contractRef ref=http://website:81/Webservice/webservice.asmx?wsdl
docRef="=http://website:81/Webservice/webservice.asmx"
xmlns="http://schemas.xmlsoap.org/disco/scl/" />

<soap address="=http://website:81/Webservice/webservice.asmx"
xmlns:q1="http:website/ws" binding="q1:ExchangeSoap"
xmlns="http://schemas.xmlsoap.org/disco/soap/" />
------------

When we change the disco file at client side, still the same error occures,
looks like the disco file is loaded at every request?

We have found a way to change to soap address to https using a
SoapExtensionReflector
described at http://forums.asp.net/thread/1160212.aspx for vs.net 2003.

but we have no idea if its possible to change the contractRef URLs and if
this can also solve the problem.


It's impossible to test the webservice without the loadbalancer, cause the
loadbalancer is not managed by us.

Regards,

Tyhrstan van den Berg

 

[Steven Cheng[MSFT]]

Hi Tyhrstan,

Thanks for your reply.

So you're still create the web reference against the web url WSDL/disco
document? I suggset you first use IE to visit the webservice asmx endpoint
and download the WSDL document(xxx.asmx?wsdl). You can save the wsdl
document into local filesystem. In Visual Studio, you can directly add web
reference against the local saved wsdl document to generate the proxy(and
change the service url to the https address when you use it at runtime).

Also, instead of using the Visual Studio "Add WebReference" add-in, you can
use the wsdl.exe utiilty to generate the client proxy:

#Web Services Description Language Tool (Wsdl.exe)
http://msdn2.microsoft.com/en-us/library/7h3ystb6(VS.80).aspx

based on my understanding, after you've generate the proxy class, it no
longer need to read the WSDL document. An exception is that you're adding
webreference in ASP.NET 2.0 website project. Since client webservice proxy
is dynamically compiled, it will frequently use the local downloaded
disco/wsdl map. If this is the case, you can consider use wsdl.exe utility
to generate the proxy, or create a separate class library project to create
the webreference and use it in ASP.NET web application.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Steven Cheng[MSFT]]

Hello Tyhrstan,

Have you got any progress on this issue? Due to the complexity of this
issue, it may require further troubleshooting, if you feel this an urgent
issue and need further assistance, I suggest you contact CSS and open a
regular support incident on this:

http://msdn.microsoft.com/subscriptions/support/default.aspx

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Esquerel]

Hello Steven,

Thank you for your suggestions in your previous message,
after whe tried the first suggestion, the following error occured:

--
Microsoft.Web.Services2.Addressing.AddressingFault: Destination
Unreachable ---> System.Exception: WSE816: The <To> header must match the
value of an incoming message's HTTP Request Url if the soap receiver does
not have an actor name. The <To> header received contained
"https://website/service.asmx" while the HTTP Request Url was
"http://website:81/service.asmx
--

We solved this issue by setting the SoapActor hardcoded like

--
<System.Web.Services.WebService(Namespace:="http://tempuri.org/WSEWebService/Service1"),
_
SoapActor("https://website/service.asmx")> _
Public Class Service1
--

This solved the problem.

Now the only issue is that the hardcoded soapactor isn't a pretty solution,
and the soapactor requires a static value..

Thank you very much.

Regards,

Tyhrstan van den Berg

 

[Steven Cheng[MSFT]]

Thanks for your followup Tyhrstan,

Glad that you've figured out the issue and got a workable solution.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Gene Wirchenko]

On Fri, 27 Jan 2012 11:28:32 GMT, Jawwad Mukhtar

[snip]

[snip]

1794 days. A new record (from what I have seen).

Related humour:
http://xkcd.com/979/

Sincerely,

Gene Wirchenko