Maven IllegalStateException (SSL related?) When loading project dependencies

I am creating a development environment on an ARM machine with the following versions of Java and Maven that are installed through apt-get :

 (xenial) craig@localhost :~$ mvn -version Apache Maven 3.3.9 Maven home: /usr/share/maven Java version: 1.8.0_91, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-8-openjdk-armhf/jre Default locale: en_US, platform encoding: ANSI_X3.4-1968 OS name: "linux", version: "3.14.0", arch: "arm", family: "unix" (xenial) craig@localhost :~$ java -version openjdk version "1.8.0_91" OpenJDK Runtime Environment (build 1.8.0_91-8u91-b14-0ubuntu4~16.04.1-b14) OpenJDK Zero VM (build 25.91-b14, interpreted mode) 

However, when I run mvn clean install in my project, it does not try to load the POM file that exists. (I can visit it in my browser.)

The stacktrace element is quite large, but it seems to have a root:

 Caused by: java.lang.IllegalStateException at sun.security.ec.ECDHKeyAgreement.deriveKey(Native Method) at sun.security.ec.ECDHKeyAgreement.engineGenerateSecret(ECDHKeyAgreement.java:130) at sun.security.ec.ECDHKeyAgreement.engineGenerateSecret(ECDHKeyAgreement.java:163) at javax.crypto.KeyAgreement.generateSecret(KeyAgreement.java:648) at sun.security.ssl.ECDHCrypt.getAgreedSecret(ECDHCrypt.java:101) at sun.security.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:1067) at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:348) at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979) at sun.security.ssl.Handshaker.process_record(Handshaker.java:914) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403) 

Unfortunately, this is not much more - Maven fails:

 Caused by: org.eclipse.aether.resolution.ArtifactDescriptorException: Failed to read artifact descriptor for org.jacoco:jacoco-maven-plugin:jar:0.7.6.201602180812 

And the stack ends with an exception thrown in deriveKey() . Did I miss some cryptographic library on my machine?

This is the new version of Xenial (16.04 LTS).

+7
java maven ssl
source share
1 answer

When installing Oracle JRE, this is an easy way out, here are the instructions if you want to use OpenJDK Zero VM specifically, be it with Maven, SSL, the ECDH key, or any other cryptographic method that is implemented in the native code in the OpenJDK default encryption service.

I assumed that the ECDHKeyAgreement.deriveKey method fails because it is a native method, and the OpenJDK Zero VM, as it is packaged in Ubuntu for the Raspberry Pi, simply cannot handle it; I am not able to debug this failure.

Ubuntu ships the cryptographic provider BouncyCastle, which is implemented in pure Java. You need to install it in the usual way:

 sudo apt install libbcprov-java* 

(it also sets documents)

Then follow the instructions in /usr/share/doc/libbcprov-java/README.Debian to make it the default crypto provider. In particular, you need to make a link to the supplier banner from the ext directory from the JRE, so do update-java-alternatives -l , which follows (in my case, I used the default settings specified in Ubuntu 16.04 Raspberry Pi server install - the specific JRE directory may change over time):

 sudo ln -s /usr/share/java/bcprov.jar /usr/lib/jvm/java-1.8.0-openjdk-armhf/jre/lib/ext/bcprov.jar 

Then edit the file /usr/lib/jvm/java-1.8.0-openjdk-armhf/jre/lib/security/java.security (call the sudo editor) by adding the line:

 security.provider.1=org.bouncycastle.jce.provider.BouncyCastleProvider 

... which lists cryptography providers and adding 1 to the priority of existing ones, so the list looks something like this:

 security.provider.1=org.bouncycastle.jce.provider.BouncyCastleProvider security.provider.2=sun.security.provider.Sun security.provider.3=sun.security.rsa.SunRsaSign security.provider.4=sun.security.ec.SunEC security.provider.5=com.sun.net.ssl.internal.ssl.Provider security.provider.6=com.sun.crypto.provider.SunJCE security.provider.7=sun.security.jgss.SunProvider security.provider.8=com.sun.security.sasl.Provider security.provider.9=org.jcp.xml.dsig.internal.dom.XMLDSigRI security.provider.10=sun.security.smartcardio.SunPCSC 

Crypto in Java should now work, albeit very slowly. Here is an example of a program that I used to confirm that this is the case if you do not want to use Maven for this:

 import java.io.InputStream; import java.net.URL; import java.net.URLConnection; public class URLGet { public static void main(String[] args) { try { URL url = new URL(args[0]); URLConnection urlConnection = url.openConnection(); try ( InputStream stream = urlConnection.getInputStream(); ) { byte[] buf = new byte[4096]; int read; while ((read = stream.read(buf, 0, buf.length)) > 0) { System.out.write(buf, 0, read); } } } catch (Exception e) { e.printStackTrace(System.err); } } } 

Point it to any https URL (e.g. java URLGet https://www.google.com/ ) to confirm that Java can handle SSL.

+9
source share

All Articles