1
votes

I am developing a Web Application with Microservice Architecture. I use docker and docker-compose to run my microservices. I want to access an api from the frontend service. But it always throws SSL certificate exception, whichs tell me that the issuer is not verified from curl. I get this error from the HttpClient in my demo MVC app: "The remote certificate is invalid according to the validation procedure."

I created a demo project for testing it, here is the github link: https://github.com/KriszW/AccessDockerContainersFromEachOtherDemo

I know the problem is within the container. Because i tested it with curl, and when i specified the --insecure attribute it worked. So i know that something is bad with the ssl certificates in my containers.

I know that i do not have any problem with the APIs, because i run them in kestral and they worked fine as well.

Something is bad with the docker containers, or images.

Thanks for your help in advance guys i realy dont know what to do now, and how to solve it.

I use the latest .Net Core 3.1 for my Web APIs and MVC app as well.

1
FWIW, it's not typical to communicate between containers/pods within a network/cluster over SSL, as it's unnecessary and just causes extra headaches like this. You'd typically let the services communicate between each other over HTTP and then terminate the HTTPS where traffic enters the network from the outside, such as through an API gateway or a reverse proxy.Chris Pratt
The error is clear - the certificate used is invalid. Most likely they are self-signed certificates which are invalid by definition. when i specified the --insecure attribute it worked. that's because the certificate is invalid and all clients will complain unless you tell them to either ignore it, or trust itPanagiotis Kanavos
I've updated my answer to provide you more information on how to mount the volume and configure the certificate.Josh E
Thanks for all of you. I manged to solve it finally :D. I managed to trust the certificate in Docker, but i think i would stick to Chris' idea, because as i can see that is the best practice right now, because i have an API gateway. Thank you very much againKriszW

1 Answers

0
votes

This is a common situation that is fortunately fairly easy to resolve even if it's not that straight-forward. A few years old but still useful is Scott Hanselman's post on the topic. This will give you some underlying background.

Your docker-compose or docker run configuration will need to specify volumes for both the certificate and for your user secrets folder, in order to supply a password for the SSL cert. Here's what that typically looks like in the volumes section of a docker-compose.yml for development:

  - ${APPDATA}\ASP.NET\Https\:/root/.aspnet/https:ro
  - ${APPDATA}\Microsoft\UserSecrets\:/root/.microsoft/usersecrets:ro

Whether you use a User Secret or not, you'll want to configure your web host (e.g., IIS, Kestrel, etc) with the PFX key and paths to your cert. Note how the volume path matches the cert path. Kestrel's config looks like this:

Kestrel": {
  "Certificates": {
    "Default": {
      "Path": "/root/.aspnet/https/MyCertificate.pfx",
      "Password": "mypassword12345", // ...

}

One direct route to this with VS Docker tooling is to right-click your project in Visual Studio and Add... Docker support. This will create DOCKERFILEs and get everything running when you hit F5 or CTRL+F5. Popping open the dockerfiles, capturing the various docker commands issued by the tooling, and inspecting running containers are all useful ways to get familiar with some of these types of tricks.

The easiest [ed: second easiest] thing to do would be to use a volume mount or docker secret to mount a certificate from the host machine's filesystem into your containers. This is how it works when you run a .net core application on Docker using Visual Studio's tools - a dev cert is generated via dotnet dev-certs and stored in your user directory. This directory is then mounted into your container and used as the SSL cert by your asp.net core application.

Because the cert is trusted by you (the requestor), [ed: and because it is shared with all containers], the certificate will be considered valid and you'll be good to go!