search

docker / for-win

Bug reports for Docker Desktop for Windows
https://www.docker.com/products/docker#/windows
1.86k stars 287 forks source link

Docker containers not trusting custom root CAs #4804

Open Falco20019 opened 5 years ago

Falco20019 commented 5 years ago

Expected behavior

Windows trusted root CAs should be trusted in Moby VM according to https://docs.docker.com/docker-for-windows/faqs/#how-do-i-add-custom-ca-certificates

Actual behavior

The certificates are not added to the MobyVM or are not trusted. This is due to the companies ZScaler root CA acting as man-in-the-middle. It worked some time ago (I asume until 2.1.0.2 or 2.1.0.0) but doesn't work with the latest (2.1.0.3) version anymore.

$>docker build .
Sending build context to Docker daemon   60.8MB
Step 1/16 : FROM mcr.microsoft.com/dotnet/core/aspnet:3.0 AS base
 ---> 675139f95df1
Step 2/16 : WORKDIR /app
 ---> Using cache
 ---> 732a4cb1bab2
Step 3/16 : EXPOSE 80
 ---> Using cache
 ---> 5bc607694586
Step 4/16 : FROM mcr.microsoft.com/dotnet/core/sdk:3.0 AS build
 ---> 4422e7fb740c
Step 5/16 : WORKDIR /src
 ---> Using cache
 ---> 8bf53cf25697
Step 6/16 : COPY ["AspNetRest.csproj", "Application/"]
 ---> Using cache
 ---> 63b318c31561
Step 7/16 : RUN dotnet restore "Application/AspNetRest.csproj"
 ---> Running in 9b82c73dfa8a
/usr/share/dotnet/sdk/3.0.100/NuGet.targets(123,5): error : Unable to load the service index for source https://api.nuget.org/v3/index.json. [/src/Application/AspNetRest.csproj]
/usr/share/dotnet/sdk/3.0.100/NuGet.targets(123,5): error :   The SSL connection could not be established, see inner exception. [/src/Application/AspNetRest.csproj]
/usr/share/dotnet/sdk/3.0.100/NuGet.targets(123,5): error :   The remote certificate is invalid according to the validation procedure. [/src/Application/AspNetRest.csproj]
The command '/bin/sh -c dotnet restore "Application/AspNetRest.csproj"' returned a non-zero code: 1

Information

Steps to reproduce the behavior

  1. Add a self-signed root certificate to your windows Trusted Root Certificate Authorities for local machine (not user account).
  2. Create an endpoint using a certificate issued by this root certificate.
  3. Try to connect to this endpoint on your local machine, it should work.
  4. Try to connect to this endpoint using any container (alpine, ubuntu, ...), it should fail.

I used the following Dockerfile. It will fail on the dotnet restore line when trying to get a connection to api.nuget.org since the connection will be signed by ZScaler root certificate, which the machine is falsely not trusting.

FROM mcr.microsoft.com/dotnet/core/aspnet:3.0 AS base
WORKDIR /app
EXPOSE 80

FROM mcr.microsoft.com/dotnet/core/sdk:3.0 AS build
WORKDIR /src
COPY ["AspNetRest.csproj", "Application/"]
RUN dotnet restore "Application/AspNetRest.csproj"
WORKDIR "/src/Application"
COPY . .
RUN dotnet build "AspNetRest.csproj" -c Release -o /app

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

FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "AspNetRest.dll"]
Falco20019 commented 5 years ago

A colleague tested it with 2.0.0.3 (31259) and it's also not working on his machine. He is in the same company network.

docker-robott commented 4 years ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale comment. Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. /lifecycle stale

Falco20019 commented 4 years ago

Still a big problem that there is no infrastructure to solve this issue.

/remove-lifecycle stale

docker-robott commented 4 years ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale comment. Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. /lifecycle stale

Falco20019 commented 4 years ago

Still a big problem that there is no infrastructure to solve this issue.

/remove-lifecycle stale

docker-robott commented 4 years ago

Issues go stale after 90 days of inactivity. Mark the issue as fresh with /remove-lifecycle stale comment. Stale issues will be closed after an additional 30 days of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. /lifecycle stale

Falco20019 commented 4 years ago

Still problematic

/remove-lifecycle stale

docker-robott commented 4 years ago

Issues go stale after 90 days of inactivity. Mark the issue as fresh with /remove-lifecycle stale comment. Stale issues will be closed after an additional 30 days of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. /lifecycle stale

Falco20019 commented 3 years ago

/remove-lifecycle stale /lifecycle frozen

dennis-yemelyanov commented 3 years ago

Hitting the same issue.

Any workarounds/plans to fix?

Falco20019 commented 3 years ago

Sadly no workaround I know of. Might be fixable by using a proxy between the docker VM and the windows host which trusts the certificates. But we are still adding the root CA to the containers/images since that’s the only reliable way to do it on multiple machines without having a special setup necessary.

tech7857 commented 3 years ago

Hi

is there any resolution to the same? We are hitting the same problem.

Falco20019 commented 3 years ago

Nope, sadly not and no reactions at all for 1.5 yrs :( It would be great if network could be proxied through the host optionally. This would resolve the issue.

berjberj1 commented 2 years ago

Big issues here for same issue

Falco20019 commented 2 years ago

Sadly no reaction from the team, even though it's over 2 years now. Maybe it will get some more love once more people are forced into Docker Pro+ through the change of the licensing.

ovation22 commented 2 years ago

Can confirm this is still an issue with Windows 10 Enterprise 20H2 (19042.1466) and Docker Desktop 4.2.0, using Zscaler 3.6.0.26.

Same with Docker Desktop 4.4.4 (73704) as well. (same machine, updated Docker Desktop)

ericis commented 2 years ago

I'd love to see an official response from the team. I can see how this would be "as designed", since a developer may want to isolate a container's context from the host system; like networking, implementations could decide what should and should not be included (e.g. certificates).

However, the OP correctly points out that the documentation suggests that this should "just work" and it does not.

thaJeztah commented 2 years ago

Windows trusted root CAs should be trusted in Moby VM according to https://docs.docker.com/desktop/faqs/#how-do-i-add-custom-ca-certificates

That section describes that CAs as configured on the host machine (macOS / Windows) will be configured the same within the VM in which the Docker Engine Daemon runs.

Docker Desktop attempts to make running containers (and the Docker Engine) function "as if" the Docker Engine is running locally on your macOS or Windows machine; for Linux containers, which require a Linux kernel, it must run in a VM, so to make it function as "close as possible" to running on your host machine, it configures the VM to use the same CAs as on the host (in addition to providing other things, such as file-sharing between the host and the VM, mapping networking ports to localhost etc.).

I can see how this would be "as designed", since a developer may want to isolate a container's context from the host system; like networking, implementations could decide what should and should not be included (e.g. certificates).

This is indeed by design; containers by default should run isolated, and not have access to resources on the host (or the VM in which it's running). This is both for security (you don't want a container you started from a "random" image to be able to access resources on your host), but also to provide a more reproducible environment ("it worked on my machine").

So giving the container access to custom CA's must be an explicit configuration of the container (which could be to bind-mount the files needed, or (depending on your use-case) adding the files to the image you use to start the container).

nwsparks commented 2 years ago

@thaJeztah If it s by design that this does not work on Windows then why does it work on Mac?

My coworkers on Mac have no issues with certificates. Everything is seamless without having to load client certs into the containers. On Windows this is not the case.

The docs as the original reporter said, suggest that this should work. It seems like there is something wrong here that needs to be fixed.

tiagotrd commented 8 months ago

I started having this issue out of the blue, and realized that I had a proxy (Fiddler Classic) running locally. Hope this helps someone else.