The host trusts the TLS-intercepting proxy's CA and `docker pull` works, so why does the JVM inside the container still fail?

## What interception does to the handshake A TLS-intercepting egress proxy does not forward your handshake. It terminates the connection itself, opens its own connection to the real destination, and presents *you* with a certificate it generated on the spot, signed by a corporate certificate authority. Every client behind that proxy therefore sees a chain rooted in an authority that no public trust store contains, and each client will reject it until that authority is added to whatever list of trusted signers that particular client consults. The word "trusted" has no global meaning on a machine. It is always relative to a store, and a container image drags at least one extra store into the picture. ## The stores on the path, and who reads which 1. **The host's system bundle**, plus `/etc/docker/certs.d/<host>/` for registry-specific CAs. This is what `dockerd` uses. Fixing it makes `docker pull` and `docker push` work, and that is the whole extent of what it fixes. 2. **The image's own OS bundle** - `/etc/ssl/certs/ca-certificates.crt` on Debian-derived images, the equivalent under `/etc/pki` on RHEL-derived ones. This is what `curl`, `wget`, `apt`, and anything linked against OpenSSL inside the container consults. It comes from the base image and knows nothing about the host it happens to be running on. 3. **The JDK's `cacerts` keystore**, shipped inside the JDK or JRE in the image. A JVM does not read `/etc/ssl/certs` at all; it reads this keystore, or whatever `-Djavax.net.ssl.trustStore` points at. So a Scala service on a JDK base image can sit in a container whose OS bundle already trusts the corporate CA and still refuse every outbound HTTPS call. Other runtimes have their own conventions - Python's `certifi`, Node's bundled roots and `NODE_EXTRA_CA_CERTS` - so "the container trusts it" is never a single fact. ## The symptom, precisely A Scala document-indexing job, running with a 128 MiB memory limit and pulling documents from an internal HTTPS endpoint, fails on its first request with: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target That is not a timeout, a DNS failure or an out-of-memory kill. "Path building failed" says the JVM received a chain and could not connect it to anything in its keystore. Confirm the interception by looking at who signed what the endpoint serves from inside the affected network: openssl s_client -connect docs.internal.example.com:443 </dev/null 2>/dev/null | openssl x509 -noout -issuer If the issuer is the corporate CA rather than a public one, you are behind the interceptor and the missing trust is your problem. ## Fixing it in the image The durable repair is at build time, in a base image the whole organisation shares, so that no application team ever has to think about it: FROM eclipse-temurin:21-jre COPY corp-root-ca.crt /usr/local/share/ca-certificates/corp-root-ca.crt RUN update-ca-certificates && keytool -importcert -noprompt -trustcacerts -alias corp-root -file /usr/local/share/ca-certificates/corp-root-ca.crt -cacerts -storepass changeit `update-ca-certificates` rebuilds the OS bundle for the OpenSSL-based tools; `keytool ... -cacerts` writes into the JDK's own keystore for the JVM. On Alpine-based images you need `apk add --no-cache ca-certificates` first. If you cannot rebuild the image, you can mount a prepared keystore and point the JVM at it with `-Djavax.net.ssl.trustStore`, but that couples the container to files on a particular host and quietly breaks the moment it is scheduled somewhere else. Note that build steps hit exactly the same wall. Proxy build arguments only tell a client *where* to connect; if the proxy is also intercepting, the very first `RUN` that fetches a dependency fails on certificate verification unless the CA is installed before it - which is another argument for putting the certificate in the base image rather than in each application's Dockerfile. ## What not to do Disabling verification in the application - a trust manager that accepts everything, `curl -k`, `-Dcom.sun.net.ssl.checkRevocation=false` cargo-culted from a forum - makes the symptom vanish and removes the only protection the client had against being fooled by something that is *not* the corporate proxy. It also hides genuine certificate expiry until it becomes an incident somewhere else. Equally, resist per-developer keystores checked into a repository. The certificate has a lifetime, and a CA rotation with the trust scattered across forty Dockerfiles is a very different exercise from a rotation with it in one base image. ## The reasoning to show in an interview The valuable answer is not the `keytool` line, it is the model: name the trust stores on the path, say which process reads each one, and observe that fixing a store only fixes the clients that read it. That model also explains the neighbouring puzzles - why the image works on a laptop off the corporate network, why the same container fails only in one data centre, and why `docker pull` succeeding tells you nothing at all about the application.