Error: Client network socket disconnected before secure TLS connection was established

Docker Desktop
, ,
1

This is my docker containers list of ports when running:

443/tcp 0.0.0.0:59541

59541/tcp 0.0.0.0:53620

59542/tcp 0.0.0.0:53621

80/tcp 0.0.0.0:59542

Is it possible to change the ones for 59541/tcp and 59542/tcp to 0.0.0.0:0?

This is my docker compose:

version: '3.4'

services:
  appone.api:
    environment:
      - ASPNETCORE_ENVIRONMENT=Development
      - ASPNETCORE_URLS=https://+:443;http://+:80
    image: ${DOCKER_REGISTRY-}apponeapi
    build:
      context: .
      dockerfile: AppONE.Api/Dockerfile
    networks: 
    - ${NETWORK}
    ports:
    - "59541:443"
    - "59542:80"

networks:
  dev-network:
      name: ${NETWORK}

This is the docker compose override:

version: '3.4'

services:
  appone.api:
    environment:
      - ASPNETCORE_ENVIRONMENT=Development
      - ASPNETCORE_URLS=https://+:443;http://+:80
    ports:
      - "59541"
      - "59542"
    volumes:
      - ${APPDATA}/Microsoft/UserSecrets:/root/.microsoft/usersecrets:ro
      - ${APPDATA}/ASP.NET/Https:/root/.aspnet/https:ro

The reason I want to change it is because at the moment, when I connect via postman to https://localhost:59541, I get Error: Client network socket disconnected before secure TLS connection was established

2

I don’t understand this question. What would you like to do exactly? Forward port from and to which port and IP address?

In the docker compose override file what would you like to achieve with this:

It means that you have services listening on these ports and you want to forward ports to these ports from random host ports

3

Hi, thanks for the reply. I removed the docker compose ports already.

My current port setup for this project is like this:

443/tcp 0.0.0.0:59541

59541/tcp 0.0.0.0:53620

59542/tcp 0.0.0.0:53621

80/tcp 0.0.0.0:59542

I would like it to be like this

443/tcp 0.0.0.0:59541

59541/tcp 0.0.0.0:0

59542/tcp 0.0.0.0:0

80/tcp 0.0.0.0:59542

4

If you try it and it gives you an error message or does not work, then it is probably not possible :slight_smile: I still don’t understand that port configuration but I ignore that for the moment since it may not be relevant. I assume you know what you are doing. I have never tried 0 as a target port. I googled it and if I understand it, this is a special port to tell the system to find a suitable port. I don’t know if it is possible to use it as a target port or just for a listening address (I guess this is the case), but I would not do it anyway. When you run a container, you want to know what service is listening on what port. And since it is inside a container, you don’t even need to worry about that a port is already used by an other service.

So since I can’t do more than check that configuration myself on my machine, which you can do too, I leave it to you. :slight_smile: If you get an arror message that you don’t understand, we can try to explain that to you.

update:

If the error message in the title is the result of your test using port 0 as target, than probably this is the answer.

Sorry, I forgot the title when I came back to to topic :slight_smile:

5

Hi! Thanks for taking the time to answer this. I am unfamiliar with Docker as I am new to it.

This port configuration(with other port numbers):

443/tcp 0.0.0.0:59541

59541/tcp 0.0.0.0:0

59542/tcp 0.0.0.0:0

80/tcp 0.0.0.0:59542

was set automatically when I ran my docker compose for my other project. It works properly.

The issue now is that I am unable to use Postman to connect to my api because I get this error:
Error: Client network socket disconnected before secure TLS connection was established

I looked around and I think the end result I want is to make my container listen to 0.0.0.0:0 as shown here: https://www.reddit.com/r/docker/comments/oa84r8/not_able_to_send_requests_to_service_hosted_on/

I believe no traffic is entering the container at the moment due to that.

6

So after tinkering around and removing the ports from the override for all my projects, I discovered something interesting:

My other project which has 1 container works and has only 2 listening ports:

443/tcp - 0.0.0.0:59527
80/tcp - 0.0.0.0:59528

However, AppOne.Api which has this port setup,

443/tcp - 0.0.0.0:59541
80/tcp - 0.0.0.0:59542

shows the same error: Error: Client network socket disconnected before secure TLS connection was established

I’m at a loss now.

EDIT:

I get this error with https://localhost:59541

If i try with http://localhost:59542, I get this:

Error: connect ECONNREFUSED ::1:443

7

A further update:

This is the strangest thing. This is my Dockerfile:

#See https://aka.ms/containerfastmode to understand how Visual Studio uses this Dockerfile to build your images for faster debugging.

FROM mcr.microsoft.com/dotnet/aspnet:3.1 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
ENV ASPNETCORE_URLS=http://+:80
ENV ASPNETCORE_ENVIRONMENT=Development

FROM mcr.microsoft.com/dotnet/sdk:3.1 AS build
WORKDIR /src
#Add the nuget line if building locally
COPY ["../NuGet.Config", "."]
COPY ["AppOne.Api/AppOne.Api.csproj", "AppOne.Api/"]
COPY ["AppOne.ClassLibrary/AppOne.ClassLibrary.csproj", "AppOne.ClassLibrary/"]
COPY ["AppOne.Data/AppOne.Data.csproj", "AppOne.Data/"]
COPY ["AppOne_AS.Connect/AppOne_AS.Connect.csproj", "AppOne_AS.Connect/"]
RUN dotnet restore "AppOne.Api/AppOne.Api.csproj"
COPY . .
WORKDIR "/src/AppOne.Api"
RUN dotnet build "AppOne.Api.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "AppOne.Api.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "AppOne.Api.dll"]

When I run this command:

docker build -f AppOne.Api\Dockerfile --force-rm -t apponeapi .

docker rm --force appone

docker run -d -p 59541:80 --name appone apponeapi

It runs perfectly without https. I am unable to run this with Https as for some reason my env variables arent being read and I will get an invalid cert error.

Does that mean that theres something wrong with my docker compose? How am I able to run this just fine?

8

New update after a few hours:

I discovered what the issue was but still have no idea on how to solve it. It has something to do with my https.

This is my current Docker Compose file:

version: '3.4'

services:
  appone.api:
    image: ${DOCKER_REGISTRY-}apponeapi
    build:
      context: .
      dockerfile: AppOne.Api/Dockerfile
    networks: 
    - ${NETWORK}
    ports:
    - "59541:80"
      
networks:
  dev-network:
      name: ${NETWORK}

When I run this:

Snippet

docker-compose up --force-recreate --build -d

I am able to get it up and running but ONLY for http connections.

The moment I add port 443 to it is when I get all the previous errors. Does anyone know how to solve this issue?

9

In the referred tpic that is not port 0, just the IP address to listen on every available IP addresses. I would understand that, but you want to use port 0 as target port.

HTTPS is not just a choice that you make and tell the server to listen on HTTPS protocol. You need to provide TLS certificates. This is true with and without Docker too. I don’t see certificates in your shared codes.

Again. I don’t see any certificate settings in your code.

10

Hi rimelek,

Here is the latest docker compose file that I tried using. Its still giving me the same error:

version: '3.4'

services:
  appone.api:
    image: ${DOCKER_REGISTRY-}apponeapi
    environment:
      - ASPNETCORE_ENVIRONMENT=Development
      - ASPNETCORE_URLS=https://+:443;http://+:80
      - ASPNETCORE_Kestrel__Certificates__Default__Password=
      - ASPNETCORE_Kestrel__Certificates__Default__Path=/https/AppOne.Api.pfx
    build:
      context: .
      dockerfile: AppOne.Api/Dockerfile
    networks: 
    - ${NETWORK}
    ports:
    - "59541:80"
    - "59542:443"
    volumes:
      - ~/.aspnet/https:/https:ro
      
networks:
  dev-network:
      name: ${NETWORK}
11

Since I am not a ASPNET developer, I have no idea how TLS works with ASPNET. If you can make it work without Docker or at least you can enter the container and check the HTTPS acces from inside the container without error, than we can try to figure out what is required to make it work from outside.