Where the Request Failed
The JVM running Maven cannot validate the HTTPS certificate chain of the repository, so Maven refuses the connection.
Maven is telling you the request failed before it got a clean response back. Treat the connection path and the failing environment as the first suspects, not the package or image name.
Fix certificate trust and TLS
Start by proving the failing machine can reach the right host cleanly. Until DNS, routing, proxy, and trust look sane in that exact environment, retrying the install or pull is mostly noise.
Determine whether you are connecting directly to the repository or through a corporate TLS proxy or VPN.
Run mvn -v first so you know exactly which Java runtime and trust store you are fixing.
If the repository is internal or TLS is intercepted, obtain the correct root CA certificate (and any required intermediates).
Create a dedicated trust store and import the CA:keytool -importcert -alias repo-ca -file /path/to/ca.pem -keystore /path/to/truststore.jks
Tell Maven and Java to use that trust store (for example via MAVEN_OPTS or .mvn/jvm.config): -Djavax.net.ssl.trustStore=/path/to/truststore.jks -Djavax.net.ssl.trustStorePassword=<password>.
Prefer that dedicated trust store over modifying the global JDK trust store unless you need a machine-wide fix.
If you control the repository, fix the server TLS configuration to serve a complete, valid chain.
Manual TLS validation checklist
Confirm the repository URL Maven is using by copying it from the error output or mvn -X logs.
Confirm which Java runtime Maven is using:mvn -v (then compare that runtime with the one used in CI or your container base image).
Inspect the certificate chain served by the host:openssl s_client -showcerts -connect <host>:443 -servername <host> </dev/null
If you already have the correct root CA certificate, verify whether it is trusted by the JVM trust store you actually plan to use.
Why It Happens
Usually this comes down to the repository is using a certificate signed by a CA that the JVM does not trust, a corporate proxy is intercepting HTTPS and presenting a certificate signed by an internal CA, the server is serving an incomplete chain (missing intermediate CA certificates), or system time is incorrect, which can cause certificate validity checks to fail.
Prove the Failing Environment Can Reach It
Re-run the original Maven goal and confirm the PKIX error no longer appears, and confirm Maven can download at least one artifact from the affected repository.
How Maven verifies TLS certificates
Maven uses the JVM's TLS implementation to connect to HTTPS repositories. The JVM must trust the certificate chain presented by the repository (leaf + intermediates up to a trusted root CA). Corporate TLS interception proxies commonly cause this error if the corporate root CA is not trusted by the JVM.
Examples
[ERROR] PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
sun.security.validator.ValidatorException: PKIX path building failedPrevent Repeat Connectivity Failures
To prevent this, standardize Java runtimes and trust store configuration across developer machines, CI runners, and container images, avoid TLS interception for build traffic when possible, otherwise, distribute the corporate root CA as part of build tooling, and monitor certificate expiry and chain completeness for internal repositories.
Docs and source code
github.com/apache/maven/blob/maven-3.9.6/maven-core/src/main/java/org/apache/maven/project/DefaultProjectDependenciesResolver.java
Maven surfaces resolver transfer failures by rethrowing a DependencyResolutionException that includes the underlying SSL/PKIX failure message (e.getMessage()). - GitHub
String msg = "Could not resolve dependencies for project " + project.getId() + ": " + e.getMessage();
DependencyResolutionException dex = new DependencyResolutionException(msg, e);
dex.setResult(e.getResult());
throw dex;