My company is using self-signed TLS certificates for internal IT systems. In order to connect to said systems from Linux servers (Ubuntu 20.04 LTS), e.g., by means of curl, we have to put the CA certificate mycompany.crt
in /usr/local/share/ca-certificates
and do a sudo update-ca-certificates
. Then everything works fine on the servers.
Now, when I run a container by executing podman run -it ubuntu:20.04
and do a
curl https://myinternalserver.mycompany/api/foo
I get an error
curl: (60) SSL certificate problem: unable to get local issuer certificate
Please note that curl
was only an example. In our production case there are .NET applications and other programs inside the container that fail with similar errors due to missing CA certificates.
What’s the easiest way to make our internal CA certificates from the host OS (in /usr/local/share/ca-certificates
) known to the container?
Should I mount /usr/local/share/ca-certificates
into the container and execute update-ca-certificates
in my ENTRYPOINT
/ CMD
?
Or should I even bake the CA certificates into my container images? But then I would have to build custom images for each and every third-party container only for the purpose of the CA certificates.
2
Answers
The only viable way to work with containers and certificates is volumes. Baking certificates into images is a nightmare. Thankfully, this question has been quite thoroughly answered here. Hopefully this helps
In general, we need a consistent way to add/remove ca-certificates to the set of ca-certificates that tools like podman and docker start with for basic communication with the rest of the world.
Where does podman get its ca-certificates from? I’m NOT talking about registry credentials.
The location of that directory/file on at least two platform groups, Debian and Redhat would be invaluable.
If I can adjust the CA certs on my host to allow curl to function, why can’t that configuration convey to curl running in a container on the same host? On ubuntu curl looks at /etc/ssl/certs/ca-certificates.crt.
Apologies to those offering to manipulate the content of Dockerfiles (I’ve got 10,000+ Dockerfiles and they come from multiple sources and they’re constantly being updated) or change the command line arguments used to launch a container ( podman/docker used by k8s for example ) – these are one off non-scalable solutions that avoid answering the underlying problem.