Can confirm this. Actually what is strange is that I have the service endpoint configured like this

      app.UseServiceModel(serviceBuilder =>
      {
        serviceBuilder.AddService<Service>();
        serviceBuilder.AddServiceEndpoint<Service, IService>(new BasicHttpBinding(BasicHttpSecurityMode.Transport), "/Service.svc");
        var serviceMetadataBehavior = app.ApplicationServices.GetRequiredService<ServiceMetadataBehavior>();
        serviceMetadataBehavior.HttpsGetEnabled = true;
      });

With this in launchSettings.json

{
  "iisSettings": {
    "windowsAuthentication": false,
    "anonymousAuthentication": true,
    "iis": {
      "applicationUrl": "https://localhost/CoreWCFService1",
      "sslPort": 0
    }
  },
  "profiles": {
    "CoreWCFService1": {
      "commandName": "Project",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      },
      "applicationUrl": "https://localhost:7081;http://localhost:5081"
    },
    "IIS": {
      "commandName": "IIS",
      "launchBrowser": true,
      "launchUrl": "Service.svc"
    }
  }
}

So I'm saying to host it https://localhost/CoreWCFService1/Service.svc but it produces 400 errors there BUT it actually works at https://localhost/CoreWCFService1, showing the well known blue page.

The WSDL is also made available at https://localhost/COREWCFSERVICE1?singleWsdl

I've been having what I'd suspect is the same issue with self-hosting - I'm working on drop-in replacement CoreWCF code to replace old WCF.

In WCF I can have an endpoint http://localhost:1234/Test which will serve the help page. With CoreWCF a base address of http://localhost:1234/Test and the endpoint address empty leads to service calls working but a 400 for the help page. If I add something as the endpoint address the help page then works, but of course the client URL has been changed.

Edit: I just tried something else and bingo - I had added a URL to serviceOptions.BaseAddresses as per the blog post on metadata, and once I removed this and set the endpoint address to /Test it worked as expected. Maybe that blog post needs a revision...?

I'm also running into this issue.

Having the same issue. Whats the workaround/solution here?

I can confirm this issue and that following settings does work around the error:

serviceMetadataBehavior.HttpGetUrl = new Uri("http://localhost/");
serviceMetadataBehavior.HttpsGetUrl = new Uri("https://localhost/");