Resolving WCF Exception: HTTP Scheme Mismatch in HTTPS-Only IIS Websites

Problem Context and Error Analysis

When deploying Windows Communication Foundation (WCF) services, developers often encounter the error message: Could not find a base address that matches scheme http for the endpoint with binding BasicHttpBinding. Registered base address schemes are [https]. This occurs specifically when hosting the service on an IIS website configured with only HTTPS (port 443) bindings. The core issue stems from a mismatch between the WCF endpoint configuration and the available base address schemes registered by IIS.

Technically, WCF relies on matching endpoint bindings to available base addresses during runtime. If an IIS site has only HTTPS bindings, the system registers https as the sole scheme, while default or misconfigured basicHttpBinding may implicitly or explicitly depend on HTTP. This discrepancy prevents WCF from finding a suitable base address to activate the service.

Core Solution: Configuring basicHttpBinding Security Mode

Based on the best answer (score 10.0), the key to resolving this error lies in correctly configuring the security mode of basicHttpBinding. Below is a refactored and annotated configuration example:

<system.serviceModel>
  <bindings>
    <basicHttpBinding>
      <binding name="secureBasicHttpBinding">
        <security mode="Transport">
          <transport clientCredentialType="None" proxyCredentialType="None" />
        </security>
      </binding>
    </basicHttpBinding>
  </bindings>
  <services>
    <service name="YourNamespace.YourService">
      <endpoint
        name="SecureEndpoint"
        address=""
        binding="basicHttpBinding"
        bindingConfiguration="secureBasicHttpBinding"
        contract="YourNamespace.IYourContract" />
    </service>
  </services>
</system.serviceModel>

In this configuration, security mode="Transport" directs WCF to use transport-layer security (i.e., HTTPS), aligning it with the IIS HTTPS binding. Setting clientCredentialType and proxyCredentialType to None indicates no client authentication is required; adjust these parameters based on actual security needs. The endpoint address is set to an empty string (address=""), allowing WCF to automatically use the IIS base address, simplifying setup.

Additional Configuration Adjustments and Considerations

Beyond binding configuration, other settings must be adjusted for compatibility. First, disable HTTP-related metadata retrieval:

<serviceMetadata httpGetEnabled="false" httpsGetEnabled="true" />

This prevents WCF from attempting to fetch metadata over HTTP, avoiding potential conflicts. Second, review and update protocol mappings:

<protocolMapping>
  <add binding="basicHttpsBinding" scheme="https" />
</protocolMapping>

This ensures all HTTPS requests are correctly mapped to basicHttpsBinding, reinforcing scheme consistency.

Supplementary References for IIS and Project Configuration

Other answers offer valuable supplementary insights. For instance, the answer with a score of 6.9 mentions setting SSLEnabled = true in Visual Studio project properties, which is crucial for IIS Express in development environments to ensure proper HTTPS binding during local debugging. The answer scoring 5.0 notes that in some legacy or specific setups, adding both HTTP and HTTPS bindings in IIS might be necessary, though this is not a best practice; modern configurations should prioritize pure HTTPS environments.

The answer with a score of 4.6 emphasizes checking IIS binding configuration: in IIS Manager, right-click the site, select "Edit Bindings," and verify that HTTPS binding exists with correct certificate settings (e.g., using IIS Express development certificate). It also suggests adding a wsHttpBinding endpoint as an alternative, but note that wsHttpBinding differs from basicHttpBinding in features and compatibility; choose based on specific requirements.

In-Depth Principles and Best Practices

To fully grasp this issue, delve into WCF's address matching mechanism. During initialization, WCF collects all available base addresses (from IIS bindings or self-hosting configurations) and filters them based on the endpoint's binding scheme (e.g., HTTP, HTTPS). When only HTTPS bindings are available, any configuration relying on HTTP will fail. Thus, explicitly setting security mode="Transport" in all binding configurations is critical.

Additionally, consider using basicHttpsBinding as an alternative to basicHttpBinding, as it defaults to transport security, simplifying configuration. For example:

<endpoint binding="basicHttpsBinding" ... />

For production deployments, implement robust certificate management and test compatibility across various clients (e.g., .NET applications, web browsers). Monitoring tools like WCF tracing logs can aid in diagnosing more complex configuration issues.

Conclusion and Extended Applications

By applying the above adjustments, WCF services can run stably on IIS websites with only HTTPS bindings. Key steps include: configuring basicHttpBinding security mode as Transport, disabling HTTP metadata retrieval, and verifying IIS bindings and project settings. These principles also apply to other binding types (e.g., wsHttpBinding) with appropriate security adjustments.

For advanced scenarios, such as hybrid environments requiring both HTTP and HTTPS support, multiple endpoints or custom bindings can be configured. Regardless, ensuring binding schemes match base addresses is fundamental to avoiding such errors. By deeply understanding WCF architecture and IIS integration, developers can deploy and maintain secure web services more flexibly.