clientaccesspolicy.xml not being requested via HTTPS

0
votes

I have a silverlight app that has been using http to communicate w/self-hosted WCF services during development. I am now securing the services via https. I am getting an error I had back at the beginning of the project:

An error occurred while trying to make a request to URI 'https://localhost:8303/service'. This could be due to attempting to access a service in a cross-domain way without a proper cross-domain policy in place, or a policy that is unsuitable for SOAP services. You may need to contact the owner of the service to publish a cross-domain policy file and to ensure it allows SOAP-related HTTP headers to be sent. This error may also be caused by using internal types in the web service proxy without using the InternalsVisibleToAttribute attribute. Please see the inner exception for more details.

My clientaccesspolicy.xml file is setup to allow access from http://* and https://*. The only difference is using http vs https. Before I switched to https I could see (via Fiddler) the clientaccesspolicy.xml file being requested, but now I cannot. All I see now is two calls to CONNECT localhost:8303 HTTP/1.0...it seems to be hitting the server root, but not requesting the clientaccess file. Any ideas?

2
wcfsilverlightsilverlight-3.0

2 Answers

2
votes

Are you using a self-signed cert? And if so, have you added the server domain (looks like your service is on localhost given the error message) as a certificate exception in your browser?

This may not be your problem, but I have gotten security exceptions before trying to access WCF services via SSL with a self-signed cert when the domain was not explicitly added as an exception in the browser settings. If you are accessing your application via HTTP but your services via HTTPS the browser never prompts you to add the exception.

Here are a couple of blog posts that may be of some help getting SSL to work in Silverlight if that's not your problem:

http://kevindockx.blogspot.com/2009/12/getting-silverlight-to-work-over-ssl.html

http://timheuer.com/blog/archive/2008/10/14/calling-secure-services-with-silverlight-2-ssl-https.aspx

1
votes

In addition to Dan Auclair's link, the other item was Fiddler. Fiddler was setup to decrypt HTTPS traffic and was screwing up the communication. I disabled the decrypt HTTPS traffic and (in addition to Dan's suggestion) it worked.