Review Docker host trust separately from application-container CA trust

Bottom line: Test the intended application HTTPS path from its container context. Keep Docker-host trust, container trust and the planned persistence of an approved CA installation as separate review items.

Source fact: documented behavior

The Use CA certificates with Docker documentation is the primary reference.

Docker documents host CA installation for Docker operations separately from adding the CA to a container trust store during image build or at runtime. The guide warns that an SDK, runtime or framework may need additional steps beyond installing a CA in the operating-system trust store. Certificates installed directly into a running container do not persist when that container is destroyed or recreated. The Linux installation commands on the page target Ubuntu-based images or containers and require distribution-equivalent commands elsewhere.

What the source does not establish

This article concerns trust-store placement and persistence for an approved CA. It does not approve a traffic-inspection service, issue certificates or promise that every application uses the operating-system store. Keep registry client-certificate naming and authorization separate, and do not disable verification to obtain a successful request.

Applicability questions

• Which exact application request and endpoint require the approved CA?
• What host, image distribution and application runtime are involved?
• Where does that runtime obtain trusted roots?
• Should the installation be a temporary diagnostic change or a reviewed image-build change?

DSE recommendation: name the trust consumer and its lifetime

DSE recommends a trust map naming the Docker client operation, container operating-system store and application runtime as separate entries. Ask the security and application owners to identify the approved CA and intended endpoint. Retain safe certificate identifiers and authorization references instead of private material.

Inspect the actual application image and runtime before choosing installation instructions. Use the documented distribution branch where applicable and obtain the runtime-specific procedure when additional trust configuration is required. Do not copy Ubuntu commands into an unrelated image merely because a package name looks familiar.

Choose the lifetime of the change explicitly. If a temporary running-container adjustment is authorized for diagnosis, record its scope and cleanup. For a persistent deployment requirement, review the managed image-build process and the approved certificate update path. Keep an interactive diagnostic success from silently becoming an undocumented production dependency.

Test the request the application actually makes. Preserve the endpoint identity, trust configuration and relevant sanitized failure before changing anything. After an approved correction, compare the same request from the intended runtime. Keep successful host-side image retrieval as separate evidence, and ask the application owner to review any remaining name, chain, runtime or authorization issue without broadening trust indiscriminately.

Verification and evidence

Proposed verification, not performed: use an approved test endpoint and a disposable image representative of the real distribution and runtime. Record host-side Docker access separately from an application HTTPS request inside the test container. Apply only the authorized CA configuration and repeat that same request.

If persistence is required, recreate a container from the reviewed image and repeat the application check. Retain the image identity, safe CA identifier, installation method, runtime configuration and actual outcomes. Remove temporary diagnostic changes through the lab procedure. Report the specific trust consumer and lifecycle tested, without claiming universal runtime compatibility or approval of arbitrary interception certificates.

Official references

• Use CA certificates with Docker — Docker Docs.

Source review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.