-
Hello, I do have an internal Nexus repository with SSL enabled, but with a self signed certificate. In Maven I could add the certificate using the following commands: "${JAVA_17_HOME}/bin/keytool" -J-Duser.language=en -printcert -rfc -sslserver "privaterepo:8443" > foobar.pem
"${JAVA_17_HOME}/bin/keytool" -J-Duser.language=en -import -trustcacerts -cacerts -file foobar.pem -alias "privaterepo-nexus" -storepass PASSWORD Performing a But when I am in Eclipse, this fails despite the cacerts. From the trace found in error logs (and below), I can see that m2e-core is using Aether and okhttp3 (https://github.com/takari/aether-connector-okhttp/blob/master/src/main/java/io/takari/aether/okhttp/OkHttpAetherClient.java#L112). The JDK is the same (and point to JAVA_17_HOME). Is there a way to configuring the whole to allow self signed certificate ? The full trace:
|
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 7 replies
-
I don't think this is something you can configure at m2eclipe, you probbaly can configure this on maven, but I more suspect that your assumption
is wrong, has you checked that the JVM running eclipse is pointing to the |
Beta Was this translation helpful? Give feedback.
-
Another problem which make me thing the resolution does not even use the settings.xml - or at least, not all its content: I have set in my settings.xml a
This one spams warnings. @laeubi I've no problem with a test case, but I don't think it will be "simple": it still requires a Nexus repository as a proxy for central in settings.xml with a self signed certificate. |
Beta Was this translation helpful? Give feedback.
-
I ran the whole in debug and ran into this error while trying to reproduce my issue:
The error is thrown from this method: RealConnection and the implementation of OkHostnameVerifier only reads the subject alternative names (SAN) and my certificate did not have one. I did not dig into maven with debug itself but I think the difference of behaviour lies in the use of wagon-http and httpclient 4.5. Its HostnameVerifier validate the CN if no SAN name are found.. From the last commit/PR of OkHostnameVerifier square/okhttp#3764, it seems that the CN check was removed in 2018 for deprecation. Httpclient5 seems to take notice of the deprecation, but keeps the CN (see DefaultHostnameVerifier) check if no SAN are found. As for a test case, well, given it was a configuration mistake and that I honestly don't know where to begin to create a test case with jetty + ssl + repository provider + repository consumer, I'll skip it. I would however be willing to provide a test case (and issue) for the
The dependency below will produce a marker
It does not occur if the property is defined in the pom file... but it should honour the settings. Strangely, if I use another property like |
Beta Was this translation helpful? Give feedback.
I ran the whole in debug and ran into this error while trying to reproduce my issue:
The error is thrown from this method: RealConnection and the implementation of OkHostnameVerifier only reads the subject alternative names (SAN) and my certificate did not have one.
I did not dig into maven with debug itself but I think the difference of behaviour lies in the use of wagon-http and httpclient 4.5. Its HostnameVerifier validate the CN if no SAN name are found..
From the last commit/PR of OkHostnameVerif…