It looks like your remote server hasn't got HTTPS enabled and CoreWcf 1.0.0 now cares that your binding is asking for a secure transport with the code WebHttpSecurityMode.Transport. It tries to find a HTTPS base address that the server exposes and then throws that exception as the server is only exposing a HTTP address.

I've fixed this kind of issue with some 'hacky' code that makes CoreWcf think both http and https schemes are available. Take a look at the related issue below.

I've raised a related issue #663

I've tested a CoreWcf based service hosted with a linux App Service Plan in Azure and the host does not start with a HTTPS endpoint (note the actual Azure service exposes a HTTPS endpoint but the Kestral host does not). With the fix/hack in #663 the wsdl ports illustrate this:

<wsdl:port name="BasicHttpBinding_ServiceName" binding="tns:BasicHttpBinding_ServiceName">
<soap:address location="http://[::]:8080/ServiceName"/>
</wsdl:port>
<wsdl:port name="BasicHttpBinding_ServiceName1" binding="tns:BasicHttpBinding_ServiceName1">
<soap:address location="https://[::]:0/soap/ServiceName.svc"/>
</wsdl:port>

HTTPS has a 0 port as the fix added it back in a one of the base addresses. This would suggest it is impossible to expose HTTPS based binding in an Azure App Service without a fix. Potentially a Windows/IIS based service plan would work.

Hosting in the cloud is a common scenario where https offload is reasonably common. The workaround to modify the wsdl is a little ugly and requires way too much code so I think this deserves being a feature to simply tell CoreWCF that SSL offload is happening and to advertise it as https even though it's http.

Thx @allderidge.

The hack worked for me. I do have an asp.net (core) 7.0 service packaged in a docker container and hosted in Azure Container Apps. The container expose port 8080 (http) and the Envoy proxy terminates the TLS.

I was able to get the service working on both HTTP and HTTPS using but the generated wsdl has an ugly <soap:address location="http://[::]:8080/Service.svc"/>.

app.UseForwardedHeaders();

...

app.UseServiceModel(serviceBuilder =>
{
    var serviceMetadataBehavior = app.Services.GetRequiredService<ServiceMetadataBehavior>();

    serviceMetadataBehavior.HttpGetEnabled = true;
    serviceMetadataBehavior.HttpsGetEnabled = true;
    
    serviceBuilder
        .AddService<MySampleService>()
        .AddServiceEndpoint<MySampleService, IService>(new BasicHttpBinding(), "http://[::]:8080/Service.svc")
        .AddServiceEndpoint<MySampleService, IService>(new BasicHttpBinding(BasicHttpSecurityMode.Transport), "https://[::]:0/Service.svc");
});

If I follow the basic sample and use the AddService<T> with additional base addresses everything works as expected (https:// behind reverse proxy with the container exposing only the http://).

const string WSDL_HOST= "mydomain.com";
...

app.UseForwardedHeaders();

...

app.UseServiceModel(serviceBuilder =>
{
    var serviceMetadataBehavior = app.Services.GetRequiredService<ServiceMetadataBehavior>();

    serviceMetadataBehavior.HttpGetEnabled = true;
    serviceMetadataBehavior.HttpsGetEnabled = true;

    serviceBuilder
        .AddService<MySampleService>(serviceOptions =>
        {
            serviceOptions.BaseAddresses.Add(new Uri($"http://{WSDL_HOST}"));
            serviceOptions.BaseAddresses.Add(new Uri($"https://{WSDL_HOST}"));
        })
        .AddServiceEndpoint<MySampleService, IService>(new BasicHttpBinding(), "/Service.svc")
        .AddServiceEndpoint<MySampleService, IService>(new BasicHttpBinding(BasicHttpSecurityMode.Transport), "/Service.svc");
});

The generated WSDL has now the correct address: <soap:address location="https://mydomain.com/Service.svc"/>

I had the same issue with IIS as the server host, because it starts Kestrel and apparently (warning: speculation) doesn't pass through the external address in the way that Kestrel expects. The workaround which works for me, and which might also work in Linux Azure hosting contexts, is to put the base address in appsettings.json and configure it explicitly.

appsettings.json:

{
  "AppSettings": {
    "WebRoot": "https://example.com/",
    ...

Startup code:

        var builder = WebApplication.CreateBuilder(args);

        ...

        // WCF
        var app = builder.Build();

        // HACK to work around failure to properly integrate with IIS
        var server = app.Services.GetService<IServer>();
        var serverAddresses = new ServerAddressesFeature();
        serverAddresses.Addresses.Add(builder.Configuration.GetValue<string>("AppSettings:WebRoot"));
        server.Features.Set<IServerAddressesFeature>(serverAddresses);

I've recently done an investigation into an issue around Azure Linux App Service hosting. The problem is because Azure do some tricks under the hood in their hosting, but they don't do a complete job of it. They configure Kestrel to listen on HTTP (no SSL). The actual endpoint clients talk to are a reverse proxy which handles the SSL negotiation, and it forwards the request over HTTP to your app. But because the request originally came in over HTTPS, they fix up the HttpRequest to make it look like it's an HTTPS request. They should have fixed up the listen url's in the WebHost to reflect the external url's as they are saying they are only listening on HTTP, but presenting HTTPS requests, and there's breaking the CoreWCF logic. I did work out a simple workaround though. You configure CoreWCF as though it's accepting HTTPS request (e.g. BasicHttpBinding with security mode of Transport to trigger use of SSL), and then you override the base addresses for your service to have an https address. By default we copy over the addresses from IServerAddressesFeature, which as mentioned won't match. The trick is to clear all the base addresses before adding the new one:

    serviceBuilder.AddService<MyService>(serviceOptions =>
    {
        serviceOptions.BaseAddresses.Clear();
        serviceOptions.BaseAddresses.Add(new Uri("https://localhost/"));
    });

CoreWCF doesn't care about the hostname or the port number when setting up the listeners, it just matches on the scheme (http vs https). If you want a different hostname to appear in the WSDL, you can put that hostname in here.

Hopefully this helps.

Did anybody get this working in IIS configuration where the WCF service is hosted in sub path?

@Havunen, what exception are you getting?

The server responds bad request 400 and nothing else.
I later found that there is already issue for that: #741