How do I get SSL to work with .net core and Google Compute Engine?

Question

I have a .net core API project with the following dockerfile:

FROM mcr.microsoft.com/dotnet/aspnet:5.0.0-buster-slim AS base
WORKDIR /app
EXPOSE 443
FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build
WORKDIR /src
COPY ["API/API.csproj", ""]
RUN dotnet restore "./API.csproj"
COPY . .
WORKDIR "/src/."
RUN dotnet build "API/API.csproj" -c Release -o /app/build
FROM build AS publish
RUN dotnet publish "API/API.csproj" -c Release -o /app/publish
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "API.dll"]

I have successfully pushed this image to the Google Cloud Artifact Registry and have created a Google Cloud Compute Engine instance with it. I have set it up with https only and am failing to call it. Postman says Error: connect ECONNREFUSED XX.XXX.XXX.X:443. If I switch from https to http only I can reach the instance and it works as expected but is of course not as secure so I don't want to stick with it. It's set up with a static IP so that I can point my subdomain to it. What am I missing?

Answer 1

Your problem may be related to your container HTTPS configuration.

Please, consider review the documentation provided by Microsoft when describing how to develop ASP.NET Core Applications with Docker over HTTPS and Hosting ASP.NET Core images with Docker Compose over HTTPS. This related question could be of help as well.

Basically, you need to provide different environment configuration properties that define, respectivelly, the URLs valid for your application, the HTTPS listen port, the path to the SSL certificate to use, and the password that protects that certificate:

ASPNETCORE_URLS="https://+;http://+"
ASPNETCORE_HTTPS_PORT=8001
ASPNETCORE_Kestrel__Certificates__Default__Password="password"
ASPNETCORE_Kestrel__Certificates__Default__Path=\https\aspnetapp.pfx

As indicated in the GCP documentation, you could provide this environment information using the GCP Web Console or the gcloud CLI, in the later case using either the --container-env or the --container-env-file flags.

As indicated in the aforementioned SO question, I think you could take advantage of the multi stage Docker build process to pass this environment information as well.

Due to the fact that the containers deployed in Compute Engine share the host network, please, be sure that you have configured the necessary firewall rules to allow access to your container ports.

In order to access your certificate from your container I think you probably have two options.

On one hand, you can include the certificate in your image as part of the build process. It has the obvious drawback that it will make the certificate more accessible, it is a less secure solution, although it can be mitigated if you deploy your image to a non public repository; in addition, take into account that you still need the password for the pfx, so, with caution, it could be a valid solution.

In addition, as described in the GCP documentation, you can mount a host directory and make it accessible as a volume to your container, and store the certificate in that directory. In certain images, in order to automate the distribution progress, you can use the --metadata flag and the startup-script key for instance to provide the necessary information about how to access the certificate. But... where to obtain the certificate in first place? Ideally it may be stored in Google KMS in an encrypted form or perhaps within Google Secrets. This approach is suggested for instance in this article, although I personally have never tried it.

Having said that, in my opinion, instead of trying to customize your container, a better solution will be to configure a HTTPS load balancer in front of your VMs: in addition to high availability and scalability, ease of maintenance, etcetera, regarding the HTTPS configuration, you only need to provide your certificate details when configuring your load balancer frontend; you can request a Google managed certificate as well if necessary.

Please, be aware that if you follow this second option, you do not longer need to configure HTTPS in your application itself, it can safely run on port 80. The idea is to delegate HTTPS handling to the load balancer and use the load balancer frontend to provide SSL termination, freeing your application from that responsibility.

Answer 2

You have to tell the webserver of the docker image where the asp.net app runs to use also the https protocol.

You should achieve this, by injecting the environment variable ASPNETCORE_URLS with the following value https://+;http://+.

Further information about this env variable is availabel in the docs