Which Docker CA Store Does the Proxy Failure Point To?
Separate image pulls, build downloads and container application requests when trusting an authorized inspection CA.
Adding a company CA inside a container cannot fix a colleague's failed image pull. A successful pull likewise does not prove that the application inside the image trusts the inspected HTTPS service.
| Operation | Trust to investigate |
|---|---|
| Pull an image through the organization's inspection proxy | The host or Docker environment performing the pull |
| Download during an image build | The build environment and its downloader |
| Call an HTTPS service from the running application | The image's OS store or the application's own trust configuration |
Trace the error to the process verifying the peer, then confirm the issuer, hostname and handshake stage. An authorized inspection service may sign the destination certificate with the organization's CA. A TLS failure at an HTTPS proxy listener is not automatically a failure of the destination certificate reached through it. Entering the proxy IP supplies neither trust material.
Install the approved public issuer certificate through the relevant host, image distribution or application's supported mechanism. Docker's CA guidance covers host and container stores, but a CentOS path is not a portable Debian or Windows instruction. Appending to a generated bundle can be undone by an update; a Java application or another client with its own CA configuration may ignore the OS bundle altogether.
For persistent application trust, put the change in the approved image or application configuration process. An interactive edit to one running container will be absent from the next container created from the image.
Distribute only the required public trust certificate through the authorized channel. Never put a CA private key in an image or treat an unfamiliar public proxy's root-install request as ordinary setup. Keep hostname and chain verification enabled after the intended store is configured.