IllegalStateException geworfen von Maven (SSL-bezogenen?) beim herunterladen von projektabhängigkeiten

Ich bin einrichten einer Entwicklungsumgebung, die auf einer ARM-Maschine, mit den folgenden Versionen von Java und Maven installiert über apt-get:

(xenial)[email protected]:~$ 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)[email protected]:~$ 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)

Jedoch, wenn ich eine mvn clean install auf mein Projekt, es scheitert der Versuch zum herunterladen einer POM-Datei, die hat vorhanden. (Kann ich einen Besuch in meinem browser.)

Dem stacktrace ist Recht groß, aber der root scheint zu sein:

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)

Gibt es leider nicht viel mehr drin – Maven schlägt fehl mit:

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

Und der stack endet mit der Ausnahme in deriveKey(). Bin ich etwas fehlt crypto library auf meinem Rechner?

Dies ist eine frische Installation von Xenial (16.04 LTS).

  • Hi @JohnRichardson – landete ich lösen das Problem, indem Sie einfach die Umstellung auf die Oracle JDK. Ich habe nie herausgefunden, was das root-Problem ist, aber ich war ursprünglich die Wahl OpenJDK wegen seiner up-to-date-version (und einfache Installation) aus dem Paket-manager. Ich landete nur die Installation der Oracle-version manuell, direkt von Ihrer website.
InformationsquelleAutor Craig Otis | 2016-05-11



One Reply
  1. 9

    Während der Installation des Oracle-JRE ist die einfache Lösung, hier sind die Anweisungen für den Fall Sie möchten, verwenden Sie die OpenJDK Zero VM-spezifisch, sei es mit Maven, SSL, den ECDH-key-Vereinbarung oder einer anderen crypto-Methode, implementiert in nativen code in die OpenJDK-Standard-Krypto-Anbieter.

    Ich bin davon ausgegangen, dass die ECDHKeyAgreement.deriveKey – Methode schlägt fehl, weil es eine native-Methode und die OpenJDK Zero VM verpackt in Ubuntu für Raspberry Pi können einfach nicht damit umgehen; ich bin nicht ausgerüstet, um zu Debuggen, die scheitern.

    Ubuntu-Pakete der BouncyCastle crypto-provider, implementiert in Java. Sie müssen installieren Sie es wie gewohnt:

    sudo apt install libbcprov-java*

    (das installiert auch die docs)

    Dann Folgen Sie den Anweisungen in /usr/share/doc/libbcprov-java/README.Debian zu machen, die Standard-Krypto-Anbieter. Insbesondere müssen Sie, um einen link zu dem Anbieter Glas aus dem ext-Verzeichnis der JRE, also eine update-java-alternatives -l gefolgt von (in meinem Fall – ich habe mit der standardmäßig in Ubuntu 16.04 Raspberry Pi server installieren – die einzelnen JRE-Verzeichnis kann in der Zeit ändern):

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

    Bearbeiten Sie dann die /usr/lib/jvm/java-1.8.0-openjdk-armhf/jre/lib/security/java.security Datei (aufrufen der editor mit sudo), das hinzufügen der Zeile:

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

    …wo die Krypto-Anbieter werden aufgelistet, und das hinzufügen von 1, um die Priorität von denen, die schon da sind, so dass die Liste sieht wie folgt aus:

    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 sollte jetzt funktionieren, wenn auch sehr langsam. Hier ein Beispiel für ein Programm, das ich verwendet habe, zu bestätigen, dass es funktioniert, wenn Sie nicht wollen, um die Verwendung von Maven für die:

    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);
                    }
            }
    }

    Es auf jede https-URL (z.B. java URLGet https://www.google.com/), um zu bestätigen, dass Java kann SSL.

    • wissen Sie, wenn dies gemeldet wurde, als einen bug zu openjdk?
    • Nein, ich nicht, sorry. Ich habe nicht darüber berichtet.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.