SL4/WCF not working with HTTPS

I need help trying to get an SL4/WCF app using https on a production server. The app works perfect using http, and with https it’ll load the xap and display the login page, but I get a generic error when trying to authenticate or make wcf calls:

“An exception occurred during the operation, making the result invalid. Check InnerException for exception details.”

“[Async_ExceptionOccurred] Arguments: Debugging resource strings are unavailable. Often the key and arguments provide sufficient information to diagnose the problem. See http://go.microsoft.com/fwlink/?linkid=106663&Version=4.0.60310.0&File=System.dll&Key=Async_ExceptionOccurred”

The environment is SL4 - MVVM, IIS7, Basic WCF, Silverlight fault behavior class, and authentication using the Asp.net membership provider. The website and services are located in the same directory, so I don’t think there’s a crossdomain issue – the site does work using http and fiddler doesn’t show a missing clientaccesspolicy.xml file – although I have that file installed anyways. Fiddler doesn’t provide any clues or traffic after the xap has loaded. I can also browse to and access the service directly while using https.

Any help or suggestions would be appreciated. Thanks, Max.

Here’s the web.config:

<extensions>
  <beha开发者_如何学PythonviorExtensions>
    <add name="silverlightFaults" type="Accruit.RidgeLine.Behaviors.SilverlightFaultBehavior, Accruit.RidgeLine.Behaviors, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  </behaviorExtensions>
</extensions>

<behaviors>
  <serviceBehaviors>
    <behavior name="silverlightBehavior">
      <serviceMetadata httpsGetEnabled="true" />
      <serviceDebug includeExceptionDetailInFaults="true" httpsHelpPageEnabled="true" />
    </behavior>
    <behavior name="">
      <serviceMetadata httpsGetEnabled="true" />
      <serviceDebug includeExceptionDetailInFaults="false" httpsHelpPageEnabled="true" />
    </behavior>
  </serviceBehaviors>

  <endpointBehaviors>
    <behavior name="SilverlightFaultBehavior">
      <silverlightFaults />
    </behavior>
  </endpointBehaviors>
</behaviors>

<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />

<services>
  <service name="Accruit.RidgeLine.Web.BankingService" behaviorConfiguration="silverlightBehavior" >
    <!-- Endpoint for Standard SOAP clients -->
    <endpoint address="" contract="Accruit.RidgeLine.Web.IBankingService"  
              binding="basicHttpBinding" bindingConfiguration="basicHttpBinding_IBankingService"/>
    <!-- Endpoint for Silverlight clients -->
    <endpoint address="SilverlightEndPoint" contract="Accruit.RidgeLine.Web.IBankingService"
              binding="basicHttpBinding" bindingConfiguration="basicHttpBinding_IBankingService_SilverlightEndPoint" 
              behaviorConfiguration="SilverlightFaultBehavior" />
    <endpoint address="mex" binding="mexHttpsBinding" contract="IMetadataExchange" />
  </service>
</services>


<client>
  <endpoint address="https://domainname.com/BankingService.svc"
      binding="basicHttpBinding" bindingConfiguration="basicHttpBinding_IBankingService"
      contract="BankingService.IBankingService" name="BasicHttpBinding_IBankingService" />

  <endpoint address="https://domainname.com/BankingService.svc/SilverlightEndPoint"
      binding="basicHttpBinding" bindingConfiguration="basicHttpBinding_IBankingService"
      contract="BankingService.IBankingService" name="basicHttpBinding_IBankingService_SilverlightEndPoint" />
</client>

In addition to my comment, here's a few things to check out:

Great link here, check sladapters post.

Here is the Silverlight Deployment Guide, which just launched recently and is available from MS. Pretty solid stuff there.

A lot of the issues I've run into have to do with the endpoint addresses being coded for the local machine in your ServiceReference.ClientConfig file. I keep a dev copy & a deploy copy in my solutions. Given the fact that you can navigate to the service, it's probably being referenced wrong here...

The app had been built with the wcf services included in the Silverlight web project and the binding uri was also being programmatically overridden using Uri(Application.Current.Host.Source, "..”). I separated out the wcf services into their own project and removed the uri code (which caused firewall and dsn access issues because 443 was being forwarded to another port). I still had issues using a self-signed ssl certificate though, so we had to purchase a valid one before the Silverlight client would communicate with the wcf service.