Problem:
FROM:ubuntu:20.04 but I do not have access to the outside internetubuntu:20.04 container does not have ca-certificates package, so I do not have the update-ca-certificates command availableWhat I did so far:
run the container (docker run -it --entrypoint /bin/bash ubuntu:20.04)
in the container, wiped the apt list and replaced it with my custom apt repos
echo > /etc/apt/sources.list
echo 'deb https://mycompany.internal.network/ubuntu-remote focal main restricted' >> /etc/apt/sources.list
echo 'deb https://mycompany.internal.network/ubuntu-remote focal multiverse' >> /etc/apt/sources.list
echo 'deb https://mycompany.internal.network/ubuntu-remote focal universe' >> /etc/apt/sources.list
[.....]
placed the root CA for https in /usr/local/share/ca-certificates/mycompany/
From here, IF I COULD I would just run update-ca-certificates and everything would work. I tested that by installing the ca-certificates package before hand, but in the correct CI workflow in which this container will be created, there is no access to the ubuntu upstream apt so I cannot do that, and this will be rebuilt periodically to keep the image up to date.
How do I make it trust the internal repo without using update-ca-certificates? All the articles I find point to doing that, but I cannot.
The simplest, but most dangerous approach would be to simply disable certificate verification.
The more mature and secure solution would be to provide the necessary Debian package archive(s) for installing ca-certificates manually.
You can achieve this via an additional option to apt itself, either for any or specific hosts. The APT option you are looking for is Acquire::https::Verify-Peer for any host or Acquire::https::<host>::Verify-Peer just for a specific host. Since disabling host verification for any host is even temporarily a potential dangerous act, I would suggest to go with the host specific variant - nevertheless you really shall know which registry hosts you have set in your sources.list file. Given your example, the command looks like follows.
apt-get -o Acquire::https::mycompany.internal.network::Verify-Peer=0 update
Since this sets the option only temporarily during this one invocation, you also have to set it when actually installing something (probably "ca-certificates") like follows:
apt-get -o Acquire::https::mycompany.internal.network::Verify-Peer=0 install ca-certificates
You could also set this option permanently in apt.conf but I strongly discourage this approach (especially the host unspecific variant), since it would permanently disable HTTPS host verification (for one or even any host) completely - as long as the option resides within your apt.conf.
This solution is not "as easy" as the first one, but is definitely the one to prefer regarding integrity and is actually not really much more difficult. What you would basically do is, you get the Debian package archive (*.deb) for ca-certificates and also for its dependencies, copy them over to your docker container and install them via dpkg.
While the first step (getting the Debian package archive (.deb) for ca-certificates) seems and also is fairly easy, getting all of its required dependencies is a more difficult task - at least if you do not have an equivalent "target operating system", i.e. Ubuntu 20.04. But if you do have, you could basically just run the following command to download all .deb for installing a particular package into the current working directory.
apt-get download $(apt-cache depends --recurse --no-recommends --no-suggests --no-conflicts --no-breaks --no-replaces --no-enhances ca-certificates | grep "^\w")
You can then either copy the files into the container during docker build or bind mount them later - either way you would want to simply (try to) install all of them by changing into the directory containing all the .deb files in the container context and issue:
dpkg -i *
dpkg will probably note that some packages are already installed and skip those.
Like already mentioned, this only works properly if the target container operating system matches the operating system where the packages are being downloaded. If this is not the case, you could basically just resolve and download package dependencies manually via the Ubuntu package registry index.
Regardless of the chosen solution, you will finally get a working installation for ca-certificates.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With