In this article
HTTPS can work on a host and fail in a container because their trust stores differ. Inspect the image's CA bundle and server chain, including intermediates. Installing a certificate on the host does not guarantee application trust, while verify=false merely hides the required validation.
HTTPS can work on a host and fail in a container because their trust stores differ. Inspect the image’s CA bundle and server chain, including intermediates. Installing a certificate on the host does not guarantee application trust, while verify=false merely hides the required validation.
Identify the exact failure
Record service name, time, client library and error text. Separate unknown issuer, name mismatch, expiration and network timeout. Compare the same endpoint from host and container while accounting for proxy settings. An inspecting corporate proxy may present certificates from its own CA. Trusting that CA requires an approved basis, not importing any certificate obtained during a failed connection.
Inspect the image trust store
A minimal image may omit CA certificates or contain an outdated bundle. Some applications use a separate store rather than the system store. Find the client’s documented trust configuration instead of assuming a Linux path. Preserve the base image digest and CA update source. Adding a CA at runtime can help investigation but disappears when the container is recreated. A durable fix belongs in a managed image or configuration mechanism.
Compare the server chain
The server should present suitable intermediate certificates in the correct order. A host client may already have an intermediate absent from the minimal environment; that does not make an incomplete server chain correct. In an example, one client builds trust while another reports unknown issuer. Compare received leaf and intermediate certificates before inspecting trusted roots. Do not install a leaf as a universally trusted root merely to suppress the error.
| Artifact | Purpose |
|---|---|
| Peer chain | What the server actually sent |
| CA bundle source | Where client trust originated |
| Image digest | Which environment was tested |
| Proxy configuration | Whether another TLS peer intervened |
Correct the managed boundary
Repair intermediates at the TLS endpoint if the server chain is defective. Where an internal trusted CA is required, add the verified certificate to the appropriate store and update it using the image’s documented procedure. Docker’s apt example applies to Ubuntu-like environments, not every distribution. The server’s private key is unnecessary. Confirm that the application actually uses the refreshed store rather than its own old file.
Verify recreation
Create a new container from the corrected image and configuration, then connect with chain and name verification enabled. Retain the result and trust rationale without unnecessary internal details. Repeat the normal deployment lifecycle: recovery must not depend on a manual command in a long-lived container. If one client still fails, inspect its trust settings separately. A successful host curl remains a useful control observation rather than proof of identical trust configuration across all applications.
Related operational reading: gpu containers vs vms; software stack reproducibility.