# Maven PKIX path building failed: fix dependency downloads

> Maven fails with PKIX path building failed when the JVM running it does not trust the repository's certificate, usually behind a proxy or with a private Nexus.

Source: https://ssl.sh/errors/maven-pkix-path-building-failed/
Last updated: 2026-11-10

**Maven's `PKIX path building failed` means the Java runtime that runs Maven does not trust the repository's certificate.** Usually a corporate proxy re-signs HTTPS, or a private Nexus or Artifactory uses an internal CA, and that root is missing from the JDK's `cacerts`. It is [Java PKIX path building failed](https://ssl.sh/errors/java-pkix-path-building-failed/) seen from a build tool.

## Quick fix

Import the proxy or internal root into the JDK that runs Maven.

1. Find the JDK Maven uses:

```bash
mvn -v    # look at "Java home:"
```

2. See who signed the repository certificate from this machine:

```bash
openssl s_client -connect repo.maven.apache.org:443 -servername repo.maven.apache.org -showcerts </dev/null | grep -E 's:|i:'
```

If the top issuer is your company or a proxy product rather than a public CA, get that root from IT.

3. Import it into that JDK:

```bash
"$JAVA_HOME/bin/keytool" -importcert -cacerts -alias company-proxy-root \
  -file company-proxy-root.pem -storepass changeit -noprompt
```

(On JDK 8 use `-keystore "$JAVA_HOME/jre/lib/security/cacerts"` instead of `-cacerts`.) Re-run the build; no Maven restart or cache cleanup is needed, but delete any `*.lastUpdated` files Maven left for failed downloads, or run with `-U`.

## Causes

### 1. Corporate proxy or security gateway with TLS inspection

A TLS-inspecting corporate proxy is the most common cause on office networks. Browsers work because IT installed the proxy root in the OS store; the JDK has its own store.

- **Confirm:** every HTTPS repository fails; the issuer is the proxy.
- **Fix:** import the proxy root (above), or on Windows run Maven with `-Djavax.net.ssl.trustStoreType=Windows-ROOT` so the JDK reads the Windows store.

### 2. Private repository with an internal CA

Nexus, Artifactory and GitLab package registries often run behind an internal CA.

- **Fix:** import the internal root, or keep a project-level truststore. Create one that holds the public roots plus yours:

```bash
cp "$JAVA_HOME/lib/security/cacerts" .mvn/truststore.p12
keytool -importcert -keystore .mvn/truststore.p12 -storepass changeit \
  -alias company-root -file company-root.pem -noprompt
```

Then add to `.mvn/jvm.config`:

```text
-Djavax.net.ssl.trustStore=.mvn/truststore.p12
-Djavax.net.ssl.trustStorePassword=changeit
```

### 3. Repository server with an incomplete chain

A self-hosted Nexus behind Nginx that sends only the leaf certificate fails in Java even though browsers are fine.

- **Confirm:** `openssl s_client -showcerts` lists one certificate. The [chain builder](https://ssl.sh/tools/chain-builder/) shows what is missing.
- **Fix:** configure the full chain on the server.

### 4. The wrong JDK was fixed

You imported into one JDK while Maven, the IDE, or the CI agent uses another. Check `mvn -v`, the IDE's Maven runner settings, and the CI image.

## Fixes by environment

Every fix imports the proxy or internal [root certificate](https://ssl.sh/glossary/root-certificate/) into the JDK that runs Maven. npm and pip need the same root in their own settings, see [npm unable to get local issuer certificate](https://ssl.sh/errors/npm-unable-to-get-local-issuer-certificate/).

**Maven wrapper (`mvnw`) and CI:** put the truststore options in `.mvn/jvm.config` or `MAVEN_OPTS` so every agent gets them. In Docker-based CI, import the root into the image's JDK at build time.

**IntelliJ IDEA / Eclipse:** check which JDK runs Maven (IDEA: Settings, Build Tools, Maven, Runner, JRE) and import into that one, or point it at a system JDK you already fixed.

**Gradle:** the same error appears during dependency resolution. Put the truststore in `gradle.properties`:

```properties
systemProp.javax.net.ssl.trustStore=/path/to/truststore.p12
systemProp.javax.net.ssl.trustStorePassword=changeit
```

**Linux system JDK:** on Debian/Ubuntu and RHEL-family systems, adding the root to the OS trust store (`update-ca-certificates` or `update-ca-trust`) also updates the packaged OpenJDK's cacerts.

## Don't do this

- **`-Dmaven.wagon.http.ssl.insecure=true -Dmaven.wagon.http.ssl.allowall=true`** and similar flags. They disable certificate checks for dependency downloads, which is exactly where supply-chain attacks happen.
- **Changing repository URLs to `http://`** or removing the HTTP blocker mirror from `settings.xml`.
- **Committing a truststore that contains private keys**, or one copied from an old JDK that lacks current public roots.