Which JDK does Maven use?

The one in JAVA_HOME, or the java found on the PATH if JAVA_HOME is unset. mvn -v prints it as Java home:. IntelliJ IDEA and Eclipse may run Maven with their own configured JDK, which has its own cacerts.

Can I put truststore settings in the project instead of every developer's machine?

Yes. Since Maven 3.3.1, a .mvn/jvm.config file in the project root passes JVM options to every build, for example -Djavax.net.ssl.trustStore=.mvn/truststore.p12. Commit the truststore only if it contains public certificates, never private keys.

Does switching to a mirror fix it?

Only if the failing host itself was the problem. Behind a TLS-inspecting proxy every HTTPS host fails the same way, so a mirror changes nothing until the JVM trusts the proxy root.

Why not use an http:// repository URL instead?

Maven 3.8.1 and later block plain-HTTP repositories by default because dependencies downloaded over HTTP can be replaced in transit, and the code runs in your build and your product.

Maven PKIX path building failed: fix dependency downloads

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 seen from a build tool.

Quick fix

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

Find the JDK Maven uses:

mvn -v    # look at "Java home:"

See who signed the repository certificate from this machine:

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.

Import it into that JDK:

"$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:

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:

-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 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 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.

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:

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.