1

I am trying to install trusted self-singed root certificate on microsoft/aspnetcore docker image.

I followed following threads here,

Trusted Root Certificates in DotNet Core on Linux (RHEL 7.1)

Install certificate in dotnet core docker container

It didn't work for me. here is output of docker build,

Step 10/24 : COPY corppvt_root_cert.cer /usr/local/share/ca-certificates/corppvt_root_cert.cer ---> af1674a5219c

Step 11/24 : COPY CCASRootCert.cer /usr/local/share/ca-certificates/CCASRootCert.cer ---> a2d6affc1ae1

Step 12/24 : RUN update-ca-certificates ---> Running in ca6fb1b9aa50 Updating certificates in /etc/ssl/certs... 0 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... done. Removing intermediate container ca6fb1b9aa50

from output of RUN update-ca-certificates command, it seems like it's not able to identify/store newly copied certificates as output says 0 added, 0 removed.

I am using microsoft/aspnetcore image. which i believe Ubuntu/Debian based image. so certificate location should be /usr/local/share/ca-certificates/

can someone advice what's wrong this commands and why cert store is not getting updated? Has anyone used this image before and did this ssl stuff?

Thanks in advance!

Meet101
  • 711
  • 4
  • 18
  • 35

2 Answers2

3

Your cert is not getting installed/updated because update-ca-certificates will only pick .crt, not .cer.

Just rename the extention and try again.

Jean.R
  • 466
  • 3
  • 10
-4

You shouldn't have to put certificates within your container in the first place. When using ASP.NET Core in docker containers the typical use case is configure it to have a reverse proxy (such as nginx, IIS etc) as ifs (internet facing server), which accepts the request from outside and acts as SSL termination endpoint as well as load-balancer.

The traffic from the reverse proxy to your application container isn't encrypted (its only within your own network, not via public net work). This has advantages in performance (the load balancer will do the ssl encryption) and less maintenance (if you change certificate, you do it on your reverse proxy and it applies to all the applications behind).

The reverse proxy should send X-Forwarded-* headers which tell the application behind if that request was connected using SSL (X-Forwarded-Proto header), for who it was forwarded for (X-Forarded-For, the Requesters IP - could be another reverse proxy or the end users ip) etc.

ASP.NET Core will recognize this headers and will not handle it as if it was an HTTPS request (even when the connection from reverse proxy to your app is not encrypted).

Tseng
  • 61,549
  • 15
  • 193
  • 205
  • Mind the the downvoter explain his downvotes? For docker containers this is and always was the preferred setup, with less pain when you need to change a certificate (otherwise if certs are part of container, it means you have to update every single container instead of just the loadbalancer/reverse proxy) – Tseng Jun 14 '19 at 07:15
  • I guess that it was downvoted as it does not answer the question at all. The statement is that this should not be done, instead one should use a gateway. Of course it's a good idea but what if the gateway is also a docker container under asp. net core (ocelot) ? In this case the question do have a lot of sense. There is also other valuable scenario where you need https internaly even with a gateway. – Jean.R Aug 16 '19 at 22:24
  • 2
    Downvote since the use case for ASP.Net Core in Docker cannot be generalized to receiving traffic through a reversed proxy. There are plenty of use cases where TLS sessions are needed when connecting to various resources such as databases, third party APIs, LDAP servers and what not. All these require CA certificates installed, which might not already be included in the OpenSSL standard CA Bundle. – Petter Nordlander Feb 06 '20 at 09:48
  • There are a lot of databases that use self-signed certificates and you need a trusted root CA certificate for the application to connect to those databases. It has nothing to do with rev proxy and so on. – Alexey Zimarev Aug 12 '20 at 13:44