Silverlight WCF + SSL security error - crossdomain.xml never requested

(I see several questions related to my problem but none of the solutions work for me as I am encountering this problem in production, not during local development, and I've already tried all of the proposed fixes.)

I have a Silverlight 4 application that uses WCF services hosted by IIS. In production these services are accessed over HTTPS. Despite having a valid crossdomain.xml file I still get the famous "Security error" when accessing the service:

An error occurred while trying to make a request to URI 'https://MYDOMAIN/MYSERVICE.svc'. 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. ---> System.Security.SecurityException ---> System.Security.SecurityException: Security error...

Using Fiddler I can see that no request is made to crossdomain.xml or clientaccesspolicy.xml. There is a CONNECT request to the server but that is all.

I've read that this error, though it indicates a problem with crossdomain.xml/clientaccesspolicy.xml, can also be raised when the server issues an invalid certificate. This does not seem to be the case in my scenario.

I am certain the following is set up correctly:

1. crossdomain.xml is valid and hosted in the root of the site

2. The services do work (We have other clients in various technologies that use them, including Adobe Flex which relies on crossdomain.xml.)

3. The Silverlight app does work (It works just fine with local services and services on a shared development server***)

4. The Silverlight app does not even try to request crossdomain.xml or clientaccesspolicy.xml (as confirmed by Fiddler)

5. The Silverlight app uses the proper config for accessing WCF over https. Below is the configuration:

<configuration>  
    <system.serviceModel>  
        <bindings>  
            <basicHttpBinding>  
                <binding name="BasicHttp开发者_Python百科Binding_IMyServices" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647">  
                    <security mode="Transport" />  
                </binding>  
                </basicHttpBinding>  
        </bindings>  
        <client>  
            <endpoint address="https://MYDOMAIN/MYSERVICE.svc" binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IMyServices" contract="Services.IMyServices" name="BasicHttpBinding_IMyServices" />  
        </client>  
    </system.serviceModel>  
</configuration>

What else can cause this kind of problem? Could it be because the web servers are load balanced? Or is there a problem with the certificate that I haven't noticed? If you can at least point me in the right direction that would be much appreciated.

(***Something worth pointing out: I came upon a similar problem in our development environment. The Silverlight app was unable to access WCF services on a shared development server, despite having a proper crossdomain.xml and not using HTTPS. I worked around it by adding the development server as a trusted site in IE. However this same workaround does not work for production, and even then it wouldn't be an acceptable workaround. But the fact that I had to do this in the development environment makes me worried that I've missed something along the way...)

The problem was that I was missing clientaccesspolicy.xml. Having crossdomain.xml was not sufficient in this case. I think this is because the WCF invocation was not just cross-browser but also cross-protocol (the Silverlight app was served via http but the services were served via https).

In addition, my clientaccesspolicy.xml had to explicitly allow access for http as follows:

<?xml version="1.0" encoding="utf-8"?>  
<access-policy>  
    <cross-domain-access>  
        <policy>  
            <allow-from http-request-headers="SOAPAction">  
                <!-- IMPORTANT! Include these lines -->
                <domain uri="http://*"/>  
                <domain uri="https://*"/>  
            </allow-from>  
            <grant-to>  
                <resource path="/" include-subpaths="true"/>  
            </grant-to>  
        </policy>  
    </cross-domain-access>  
</access-policy>

It now works like a charm.

A couple of things that tripped me up along the way:

• My browser was caching clientaccesspolicy.xml and crossdomain.xml. I would have to clear my cache every time I changed one of those files or it wouldn't recognize the newer version, despite the fact that IIS is configured to prevent client caching of this file.
• The requests to clientaccesspolicy.xml and crossdomain.xml were not always showing up in Fiddler. I would often see CONNECT requests instead. I don't understand the reason for this but I've learned not to rely on Fiddler to confirm these requests are being made. Perhaps I have some rogue setting somewhere (it's not the "Decrypt HTTPS traffic" setting because I already disabled it).

I have the same error, when I try to make a call to my site over http and my service was over https it failed. This error occured because my ISS had no certificate, so, when the app tried to download the clientaccesspolicy, it failed.

Take a look in any debug tool on your browser and look for clientacccesspolicy file, then check that if it is being downloaded.