Sounds crazy and nobody would ever do that, but just for a moment imagine you no longer own your infrastructure.
Imagine you just run your container on something like GKE with Kubernetes.
Imagine you build your software with something like Jenkins running in a container, using the GKE provided docker interface to build stuff in another container.
And for a $reason imagine you're not using the Google provided container registry, but your own one hosted somewhere else on the internet.
Of course you access your registry via HTTPS, so your connection is secured at the transport level.
Now imagine your certificate is at the end of its validity period. Like ending the next day.
Imagine you just do what you do every time that happens, and you just order a new certificate from one of the left over CAs like DigiCert.
You receive your certificate within 15 minutes.
You deploy it to your registry.
You validate that your certificate chain validates against different certificate stores.
The one shipped in ca-certificates on various Debian releases you run.
The one in your browser.
Maybe you even test it with Google Chrome.
Everything is cool and validates. I mean, of course it does. DigiCert is a known CA player and the root CA certificate was created five years ago. A lot of time for a CA to be included and shipped in many places.
But still there is one issue. The docker commands you run in your build jobs fail to pull images from your registry because the certificate can not be validated.
You take a look at the underlying OS and indeed it's not shipping the 5 year old root CA certificate that issued your intermediate CA that just issued your new server certificate.
If it were your own infrastructure you would now just ship the missing certificate.
Maybe by including it in your internal ca-certificates build.
Or by just deploying it with ansible to /usr/share/ca-certificates/myfoo/ and adding that to the configuration in /etc/ca-certificates.conf so update-ca-certificates can create the relevant hash links for you in /etc/ssl/certs/.
But this time it's not your infrastructure and you can not modify the operating system context your docker container are running in.
Sounds insane, right? Luckily we're just making up a crazy story and something like that would never happen in the real world, because we all insist on owning our infrastructure.