How to Quickly Resolve Docker Build Issues 'PKIX Path Building Failed' When Using Corporate Proxies
Fixing Docker Buildx SSL Errors: Overcoming "PKIX Path Building Failed" in Corporate Proxy Settings
Sudarshan leads the platform engineering capability within Deloitte Cloud & Engineering. He enjoys leading high-talent-density teams that architect, build and operate platforms that have an outsized impact on organisational performance indicators. He combines product management, architecture and engineering skills to build consensus across business units and organisational levels by showcasing a strong correlation between technology decisions and business drivers. Writings and opinions my own.
The day Docker Desktop broke
One morning your perfectly‑working docker build workflow begins throwing walls of red text:
Could not GET 'https://plugins.gradle.org/...'
PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException:
unable to find valid certification path to requested target
Cue panic, Slack pings, and a frenzied purge of every local cache you can find.
What actually happened has nothing to do with your build system or your project; it’s about which Docker builder is running your build.
TL;DR
Docker Desktop silently switched from the default
dockerbuilder todesktop‑linux(a BuildKit container/VM).That new builder doesn’t know about your company’s TLS‑inspection root certificate (Netskope, Zscaler, etc.), so every HTTPS request fails certificate validation.
Switch back to the default builder or inject your corporate CA into the BuildKit container and your builds succeed again.
What changed under the hood?
1. Docker swapped builders
docker buildx ls will show something like:
NAME/NODE DRIVER/ENDPOINT STATUS BUILDKIT PLATFORMS
default docker
\_ default \_ default running v0.23.2 linux/amd64 (+2), linux/arm64, linux/ppc64le, linux/s390x, (2 more)
desktop-linux* docker
\_ desktop-linux \_ desktop-linux running v0.23.2 linux/amd64 (+2), linux/arm64, linux/ppc64le, linux/s390x, (2 more)
desktop‑linux (or docker-container) spins up an isolated BuildKit container.
The default builder runs BuildKit inside dockerd on your host.
2. CA certificates got left behind
Corporate security appliances rewrite outbound TLS certificates with their own root.
Your host machine trusts that root.
The fresh BuildKit container does not, so Java, npm, Maven, Gradle—anything that calls out over HTTPS—explodes with PKIX path building failed.
Quick fix: roll back to the default builder
# 1. See the active builder
docker buildx ls
# 2. Switch back
docker context use default
# 3. (Optional) clean up the rogue builder & its cache
docker builder prune -a
Re‑run your build script and this time it should happily download the dependencies and build your images.
| Approach | How‑to | Pros / cons |
| Add your CA to BuildKit | bash builder=$(docker buildx inspect --format '{{.Nodes.0.Name}}') docker cp netskope.pem $builder:/usr/local/share/ca-certificates/ docker exec $builder update-ca-certificates && docker restart $builder | One‑time setup; survives reboots until you delete the builder. |
| Create a “corp‑builder” that reuses host certs | bash docker buildx create \ --name corp-builder \ --driver docker-container \ --driver-opt network=host \ --use | Keeps your CA in sync with the host; perfect for multi‑arch builds, cache‑export, etc. |
Either route removes the TLS‑validation errors while preserving advanced Buildx functionality.
What about Colima?
Colima runs Docker in an Alpine VM, not on the host; so the same rule applies: import your CA into the VM or point Colima at the host’s cert store.
Take‑aways
PKIX path building failedinside Docker usually means missing CA certificates, not broken dependencies.The host‑integrated
dockerbuilder inherits trusted roots automatically; container‑ or VM‑based builders do not.Fixes: switch back to the default builder or add your CA to BuildKit.
Understanding which builder is active saves hours of head‑scratching the next time certificates start misbehaving.
