Home Maven Error: (repeated) java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
Reply: 1

Maven Error: (repeated) java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty

Ulrich Published in 2016-09-30 09:35:28Z

Have to ask again. Someone thought it was a duplicate question and already answered and removed it from the list.

I'm using maven (mvn) batch command with windows (not m2e with eclipse) to run clean install or resolve dependencies. Sometimes, when pom.xml was changed, it is necessary to download artifacts from our nexus server. This used to work for long time for me.

But now the connection to the nexus server (https, the server uses a company owned certificate) fails with "java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty" I know, I changed the Java release. But I'm pretty sure I maintained the cacerts keystore the same way I did with the previous releases. (at leased I compared the fingerprints in both of the cacerts; they are the same).

When running the command "mvn -s -Djavax.net.debug=all -Djava.net.ssl.trustStore="C:/Programme/Java/jre1.8.0_102/lib/security/cacerts" -Djavax.net.ssl.trustStorePassword=changeit dependency:resolve", the ssl-trace says:

keyStore is :    
keyStore type is : jks
keyStore provider is : 
init keystore
init keymanager of type SunX509
trustStore is: No File Available, using empty keystore.
trustStore type is : jks
trustStore provider is : 
init truststore

Even if specifying the path and the password of the keystore in the command, the answer in the ssl trace is that it could not be found.

I've no idea what I might have changed to get to this trouble. I changed the Windows PATH-Statement, but this should not matter fro the previously described command. Any hint is appreciated

Ulrich Reply to 2016-11-17 09:13:09Z

Today I found the reason:

Way back in history I once had set the WINDOWS environment variable MAVEN_OPTS by "setx MAVEN_OPTS "-Djavax.net.ssl.trustStore....".

The path specified here does no longer exist.

It seems this setting supersedes even the request showed in my question. I consider this behaviour to be at least unexpected but anyway. When I fixed the environment variable (pointing to the new path; but I'm going to delete it anyway) the mvn-requests worked fine.

You need to login account before you can post.

About| Privacy statement| Terms of Service| Advertising| Contact us| Help| Sitemap|
Processed in 0.317007 second(s) , Gzip On .

© 2016 Powered by mzan.com design MATCHINFO