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.