Es kann kein gültiger Zertifizierungspfad zum angeforderten Ziel gefunden werden - Fehler auch nach dem Import des Zertifikats


204

Ich habe einen Java-Client, der versucht, mit einem selbstsignierten Zertifikat auf einen Server zuzugreifen.

Wenn ich versuche, auf dem Server zu posten, wird folgende Fehlermeldung angezeigt:

Es kann kein gültiger Zertifizierungspfad zum angeforderten Ziel gefunden werden

Nachdem ich einige Nachforschungen zu diesem Thema angestellt hatte, machte ich Folgendes.

  1. Der Domainname meines Servers wurde als root.cerDatei gespeichert.
  2. In der JRE meines Glassfish-Servers habe ich Folgendes ausgeführt:
    keytool -import -alias example -keystore cacerts -file root.cer
  3. Um zu überprüfen, ob das Zertifikat erfolgreich zu meinem Cacert hinzugefügt wurde, habe ich Folgendes getan:
    keytool -list -v -keystore cacerts
    Ich kann sehen, dass das Zertifikat vorhanden ist.
  4. Ich habe dann Glassfish neu gestartet und die 'Post' zurückgezogen.

Ich erhalte immer noch den gleichen Fehler.

Ich habe das Gefühl, dass dies daran liegt, dass mein Glassfish nicht die von mir geänderte Cacert-Datei liest, sondern vielleicht eine andere.

Hat jemand von euch dieses Problem gehabt und kann mich in die richtige Richtung treiben?


1
Nur um zu verdeutlichen: "Ich habe einen Java-Client, der versucht, mit einem selbstsignierten Zertifikat auf einen Server zuzugreifen.": Sie sprechen von selbstsignierten Client-Zertifikaten, nicht wahr? Gibt es eine spezielle Konfiguration für Ihre Connector-Einstellungen in Glassfish (insbesondere Trust Store-Einstellungen)?
Bruno

"Ich habe einen Java-Client, der versucht, mit einem selbstsignierten Zertifikat auf einen Server zuzugreifen.": Sie sprechen von selbstsignierten Client-Zertifikaten, nicht wahr? - Ja.
TheCoder

1
Ich habe 2 Einstellungen in Glassfish JVM gefunden: -Djavax.net.ssl.keyStore = $ {com.sun.aas.instanceRoot} /config/keystore.jks und -Djavax.net.ssl.trustStore = $ {com.sun. aas.instanceRoot} /config/cacerts.jks. Ich muss jetzt per Zertifikat zu einem von diesen hinzufügen. Können Sie bestätigen, dass es sich um den Schlüsselspeicher handelt, zu dem ich ihn hinzufüge?
TheCoder

4
Auf dem Server ist der Schlüsselspeicher für das Serverzertifikat und seinen privaten Schlüssel (der Schlüsselspeicher ist für das, was der lokalen Partei "gehört"). Der Truststore ist für die Zertifikate vorgesehen, mit denen das Vertrauen in die Remote-Partei überprüft wird. Sie sollten das Client-Zertifikat zu Ihrem Server-Vertrauensspeicher hinzufügen. (Siehe dies auch, obwohl Glassfish nicht zu sein scheint den Standard - Speicherort des JRE verwenden.)
Bruno

Das hat funktioniert, Bruno. Ich habe es meinem Glassfish Truststore hinzugefügt. Vielen Dank für Ihre Hilfe. Du auch Dirk.
TheCoder

Antworten:


155

Leider - es könnten viele Dinge sein - und viele App-Server und andere Java-Wrapper neigen dazu, mit Eigenschaften und ihrer eigenen Einstellung zu Schlüsselanhängern zu spielen und was nicht. Es kann sich also um etwas völlig anderes handeln.

Ohne Fachwerk - ich würde versuchen:

java -Djavax.net.debug=all -Djavax.net.ssl.trustStore=trustStore ...

um zu sehen, ob das hilft. Anstelle von "alles" kann man auch "ssl", Schlüsselmanager und Vertrauensmanager setzen - was in Ihrem Fall hilfreich sein kann. Wenn Sie "Hilfe" einstellen, wird auf den meisten Plattformen Folgendes aufgeführt.

Unabhängig davon - stellen Sie sicher, dass Sie den Unterschied zwischen dem Keystore (in dem Sie den privaten Schlüssel und das Zertifikat haben, mit dem Sie Ihre eigene Identität nachweisen) und dem Trust Store (der bestimmt, wem Sie vertrauen) vollständig verstehen - und der Tatsache, dass auch Ihre eigene Identität vorhanden ist hat eine Vertrauenskette zur Wurzel - die von jeder Kette zu einer Wurzel getrennt ist, die Sie benötigen, um herauszufinden, wem Sie vertrauen.

all            turn on all debugging
ssl            turn on ssl debugging

The   following can be used with ssl:
    record       enable per-record tracing
    handshake    print each handshake message
    keygen       print key generation data
    session      print session activity
    defaultctx   print default SSL initialization
    sslctx       print SSLContext tracing
    sessioncache print session cache tracing
    keymanager   print key manager tracing
    trustmanager print trust manager tracing
    pluggability print pluggability tracing

    handshake debugging can be widened with:
    data         hex dump of each handshake message
    verbose      verbose handshake message printing

    record debugging can be widened with:
    plaintext    hex dump of record plaintext
    packet       print raw SSL/TLS packets

Quelle: # Siehe http://download.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#Debug


6
Vielen Dank! -Djavax.net.ssl.trustStore = / location_of / trustStore hat mein Problem gelöst und die Debug-Informationen waren auch sehr hilfreich.
RHE

5
java -Djavax.net.debug = all -Djavax.net.ssl.trustStore = trustStore ... gibt den folgenden Fehler aus: Fehler: Hauptklasse konnte nicht gefunden oder geladen werden ...
rohith

1
Natürlich müssen Sie möglicherweise auch das Kennwort des Truststores mit -Djavax.net.ssl.trustStorePassword = changeit
user1754036

18

Hier ist die Lösung, folgen Sie dem folgenden Link Schritt für Schritt:

http://www.mkyong.com/webservices/jax-ws/suncertpathbuilderexception-unable-to-find-valid-certification-path-to-requested-target/

JAVA-DATEI: die im Blog fehlt

/*
 * Copyright 2006 Sun Microsystems, Inc.  All Rights Reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 *   - Redistributions of source code must retain the above copyright
 *     notice, this list of conditions and the following disclaimer.
 *
 *   - Redistributions in binary form must reproduce the above copyright
 *     notice, this list of conditions and the following disclaimer in the
 *     documentation and/or other materials provided with the distribution.
 *
 *   - Neither the name of Sun Microsystems nor the names of its
 *     contributors may be used to endorse or promote products derived
 *     from this software without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
 * IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
 * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT OWNER OR
 * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
 * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
 * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
 * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
 * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
 * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
 * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */



import java.io.*;
import java.net.URL;

import java.security.*;
import java.security.cert.*;

import javax.net.ssl.*;

public class InstallCert {

    public static void main(String[] args) throws Exception {
    String host;
    int port;
    char[] passphrase;
    if ((args.length == 1) || (args.length == 2)) {
        String[] c = args[0].split(":");
        host = c[0];
        port = (c.length == 1) ? 443 : Integer.parseInt(c[1]);
        String p = (args.length == 1) ? "changeit" : args[1];
        passphrase = p.toCharArray();
    } else {
        System.out.println("Usage: java InstallCert <host>[:port] [passphrase]");
        return;
    }

    File file = new File("jssecacerts");
    if (file.isFile() == false) {
        char SEP = File.separatorChar;
        File dir = new File(System.getProperty("java.home") + SEP
            + "lib" + SEP + "security");
        file = new File(dir, "jssecacerts");
        if (file.isFile() == false) {
        file = new File(dir, "cacerts");
        }
    }
    System.out.println("Loading KeyStore " + file + "...");
    InputStream in = new FileInputStream(file);
    KeyStore ks = KeyStore.getInstance(KeyStore.getDefaultType());
    ks.load(in, passphrase);
    in.close();

    SSLContext context = SSLContext.getInstance("TLS");
    TrustManagerFactory tmf =
        TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
    tmf.init(ks);
    X509TrustManager defaultTrustManager = (X509TrustManager)tmf.getTrustManagers()[0];
    SavingTrustManager tm = new SavingTrustManager(defaultTrustManager);
    context.init(null, new TrustManager[] {tm}, null);
    SSLSocketFactory factory = context.getSocketFactory();

    System.out.println("Opening connection to " + host + ":" + port + "...");
    SSLSocket socket = (SSLSocket)factory.createSocket(host, port);
    socket.setSoTimeout(10000);
    try {
        System.out.println("Starting SSL handshake...");
        socket.startHandshake();
        socket.close();
        System.out.println();
        System.out.println("No errors, certificate is already trusted");
    } catch (SSLException e) {
        System.out.println();
        e.printStackTrace(System.out);
    }

    X509Certificate[] chain = tm.chain;
    if (chain == null) {
        System.out.println("Could not obtain server certificate chain");
        return;
    }

    BufferedReader reader =
        new BufferedReader(new InputStreamReader(System.in));

    System.out.println();
    System.out.println("Server sent " + chain.length + " certificate(s):");
    System.out.println();
    MessageDigest sha1 = MessageDigest.getInstance("SHA1");
    MessageDigest md5 = MessageDigest.getInstance("MD5");
    for (int i = 0; i < chain.length; i++) {
        X509Certificate cert = chain[i];
        System.out.println
            (" " + (i + 1) + " Subject " + cert.getSubjectDN());
        System.out.println("   Issuer  " + cert.getIssuerDN());
        sha1.update(cert.getEncoded());
        System.out.println("   sha1    " + toHexString(sha1.digest()));
        md5.update(cert.getEncoded());
        System.out.println("   md5     " + toHexString(md5.digest()));
        System.out.println();
    }

    System.out.println("Enter certificate to add to trusted keystore or 'q' to quit: [1]");
    String line = reader.readLine().trim();
    int k;
    try {
        k = (line.length() == 0) ? 0 : Integer.parseInt(line) - 1;
    } catch (NumberFormatException e) {
        System.out.println("KeyStore not changed");
        return;
    }

    X509Certificate cert = chain[k];
    String alias = host + "-" + (k + 1);
    ks.setCertificateEntry(alias, cert);

    OutputStream out = new FileOutputStream("jssecacerts");
    ks.store(out, passphrase);
    out.close();

    System.out.println();
    System.out.println(cert);
    System.out.println();
    System.out.println
        ("Added certificate to keystore 'jssecacerts' using alias '"
        + alias + "'");
    }

    private static final char[] HEXDIGITS = "0123456789abcdef".toCharArray();

    private static String toHexString(byte[] bytes) {
        StringBuilder sb = new StringBuilder(bytes.length * 3);
        for (int b : bytes) {
            b &= 0xff;
            sb.append(HEXDIGITS[b >> 4]);
            sb.append(HEXDIGITS[b & 15]);
            sb.append(' ');
        }
        return sb.toString();
    }

    private static class SavingTrustManager implements X509TrustManager {

    private final X509TrustManager tm;
    private X509Certificate[] chain;

    SavingTrustManager(X509TrustManager tm) {
        this.tm = tm;
    }

    public X509Certificate[] getAcceptedIssuers() {
        throw new UnsupportedOperationException();
    }

    public void checkClientTrusted(X509Certificate[] chain, String authType)
        throws CertificateException {
        throw new UnsupportedOperationException();
    }

    public void checkServerTrusted(X509Certificate[] chain, String authType)
        throws CertificateException {
        this.chain = chain;
        tm.checkServerTrusted(chain, authType);
    }
    }

}

3
Diese Lösung hat bei mir funktioniert, aber es bedarf einer kleinen Änderung in der privaten Klasse SavingTrustManager:public X509Certificate[] getAcceptedIssuers() { return new X509Certificate[0];}
Richard

1
@ Richard, @ Paul, @ user6258309 Ich habe den Fehler Ausnahme im Thread "main" java.net.SocketTimeoutException: Zeitüberschreitung beim Lesen bei java.net.SocketInputStream.socketRead0 (native Methode) bei java.net.SocketInputStream.socketRead (unbekannte Quelle) ) Wie kann ich das beheben
Renjith Krishnan

5
Diese "so; lution" ist radikal unsicher. Verwende nicht.
Marquis von Lorne

9
Diese Antwort ist meistens Code. Es erklärt nicht, warum oder warum es nicht funktioniert.

13

Sie müssen die JSSE-Systemeigenschaften konfigurieren und speziell auf den Clientzertifikatsspeicher verweisen.

Über die Kommandozeile:

java -Djavax.net.ssl.trustStore=truststores/client.ts com.progress.Client

oder über Java Code:

import java.util.Properties;
    ...
    Properties systemProps = System.getProperties();
    systemProps.put("javax.net.ssl.keyStorePassword","passwordForKeystore");
    systemProps.put("javax.net.ssl.keyStore","pathToKeystore.ks");
    systemProps.put("javax.net.ssl.trustStore", "pathToTruststore.ts");
    systemProps.put("javax.net.ssl.trustStorePassword","passwordForTrustStore");
    System.setProperties(systemProps);
    ...

Weitere Informationen finden Sie auf der RedHat-Website .


Hatte das gleiche Problem mit Spring Boot, Spring Cloud Microservices und einem selbstsignierten SSL-Zertifikat. Ich konnte keyStore und keyStorePassword in application.properties festlegen und es sofort so funktionieren lassen, aber es gelang mir nicht, dasselbe mit trustStore und trustStorePassword zu tun. Diese Antwort hat bei mir für Trust Store funktioniert.
Mate Šimović

7

(Repost von meiner anderen Antwort )
Verwenden Sie das CLI-Dienstprogramm Keytool aus der Java-Softwareverteilung, um die benötigten Zertifikate zu importieren (und zu vertrauen! )

Stichprobe:

  1. Wechseln Sie von cli zu jre \ bin

  2. Überprüfen Sie den Keystore (Datei im Verzeichnis jre \ bin).
    Keytool -list -keystore .. \ lib \ security \ cacerts Das
    Passwort wird geändert

  3. Laden Sie alle Zertifikate in der Kette vom benötigten Server herunter und speichern Sie sie.

  4. Fügen Sie Zertifikate hinzu (bevor Sie das Attribut "Nur Lesen" in der Datei ".. \ lib \ security \ cacerts" entfernen müssen), führen Sie Folgendes aus: keytool -alias REPLACE_TO_ANY_UNIQ_NAME -import -keystore .. \ lib \ security \ cacerts -file "r: \ root.crt "

aus Versehen habe ich so einen einfachen Tipp gefunden. Andere Lösungen erfordern die Verwendung von InstallCert.Java und JDK

Quelle: http://www.java-samples.com/showtutorial.php?tutorialid=210


6

Ich hatte das gleiche Problem mit sbt .
Es wurde versucht, Abhängigkeiten von repo1.maven.org über ssl abzurufen
, es wurde jedoch festgestellt , dass "kein gültiger Zertifizierungspfad zur angeforderten Ziel-URL gefunden werden konnte".
Also folgte ich diesem Beitrag und konnte immer noch keine Verbindung überprüfen.
Also habe ich darüber gelesen und festgestellt, dass das Stammzertifikat nicht ausreicht, wie in der Veröffentlichung vorgeschlagen. Das,
was für mich funktioniert hat, war das Importieren der CA-Zwischenzertifikate in den Keystore .
Ich habe tatsächlich alle Zertifikate in der Kette hinzugefügt und es hat wie ein Zauber funktioniert.


4

Lösung bei der Migration von JDK 8 auf JDK 10

JDK 10

root@c339504909345:/opt/jdk-minimal/jre/lib/security #  keytool -cacerts -list
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN

Your keystore contains 80 entries

JDK 8

root@c39596768075:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts #  keytool -cacerts -list
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN

Your keystore contains 151 entries

Schritte zu beheben

  • Ich habe das JDK 10-Zertifikat gelöscht und durch das JDK 8 ersetzt
  • Da ich Docker Images erstelle, kann ich dies schnell mit mehrstufigen Builds tun
    • Ich baue eine minimale JRE mit jlinkas/opt/jdk/bin/jlink \ --module-path /opt/jdk/jmods...

Also, hier sind die verschiedenen Pfade und die Reihenfolge der Befehle ...

# Java 8
COPY --from=marcellodesales-springboot-builder-jdk8 /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts /etc/ssl/certs/java/cacerts

# Java 10
RUN rm -f /opt/jdk-minimal/jre/lib/security/cacerts
RUN ln -s /etc/ssl/certs/java/cacerts /opt/jdk-minimal/jre/lib/security/cacerts

2

Ich arbeite an einem Tutorial für REST-Webdienste unter www.udemy.com (REST Java Web Services). Das Beispiel im Tutorial besagt, dass wir in meinem Eclipse-Projekt "client" einen Ordner mit dem Namen "trust_store" haben müssen, der eine "key store" -Datei enthalten soll (wir hatten ein "client" -Projekt, um den Dienst aufzurufen, um SSL zu haben und "Service" -Projekt, das den REST-Webdienst enthielt - 2 Projekte im selben Eclipse-Arbeitsbereich, eines der Client, das andere der Service). Um die Dinge einfach zu halten, haben sie gesagt, dass sie "keystore.jks" vom Glassfish-App-Server (glassfish \ domain \ domain1 \ config \ keystore.jks), den wir verwenden, kopieren und in diesen "trust_store" -Ordner legen, in dem sie mich erstellt haben das Client-Projekt. Das scheint sinnvoll zu sein: die selbstsignierten Zertifikate auf dem Server ' s key_store würde den Zertifikaten im client trust_store entsprechen. Als ich dies tat, bekam ich den Fehler, den der ursprüngliche Beitrag erwähnt. Ich habe dies gegoogelt und gelesen, dass der Fehler auf die Datei "keystore.jks" auf dem Client zurückzuführen ist, die kein vertrauenswürdiges / signiertes Zertifikat enthält, und dass das gefundene Zertifikat selbstsigniert ist.

Um die Dinge klar zu halten, möchte ich sagen, dass "keystore.jks" nach meinem Verständnis selbstsignierte Zertifikate und die Datei "cacerts.jks" CA-Zertifikate (von der CA signiert) enthält. "Keystore.jks" ist der "Keystore" und "cacerts.jks" ist der "Trust Store". Wie "Bruno", ein Kommentator, oben sagt, ist "keystore.jks" lokal und "cacerts.jks" für Remoteclients.

Also sagte ich mir, hey, glassfish hat auch die Datei "cacerts.jks", die die trust_store-Datei von glassfish ist. cacerts.jsk soll CA-Zertifikate enthalten. Und anscheinend muss mein Ordner "trust_store" eine Schlüsselspeicherdatei enthalten, die mindestens ein CA-Zertifikat enthält. Also habe ich versucht, die Datei "cacerts.jks" in den Ordner "trust_store" zu legen, den ich in meinem Client-Projekt erstellt hatte, und die VM-Eigenschaften so geändert, dass sie auf "cacerts.jks" anstelle von "keystore.jks" verweisen. Das hat den Fehler beseitigt. Ich denke, alles, was es brauchte, war ein CA-Zertifikat, um zu funktionieren.

Dies ist möglicherweise nicht ideal für die Produktion oder sogar für die Entwicklung, die über das bloße Arbeiten hinausgeht. Zum Beispiel könnten Sie wahrscheinlich den Befehl "keytool" verwenden, um CA-Zertifikate zur Datei "keystore.jks" im Client hinzuzufügen. Aber hoffentlich werden dadurch zumindest die möglichen Szenarien eingegrenzt, die hier auftreten könnten, um den Fehler zu verursachen.

AUCH: Mein Ansatz schien für den Client nützlich zu sein (Serverzertifikat zum Client trust_store hinzugefügt). Es sieht so aus, als ob die obigen Kommentare zum Auflösen des ursprünglichen Beitrags für den Server nützlich sind (Clientzertifikat zum Server trust_store hinzugefügt). Prost.

Setup des Eclipse-Projekts:

  • MyClientProject
  • src
  • Prüfung
  • JRE-Systembibliothek
  • ...
  • trust_store
    --- cacerts.jks --- keystore.jks

Ausschnitt aus der Datei MyClientProject.java:

static {
  // Setup the trustStore location and password
  System.setProperty("javax.net.ssl.trustStore","trust_store/cacerts.jks");
  // comment out below line
  System.setProperty("javax.net.ssl.trustStore","trust_store/keystore.jks");
  System.setProperty("javax.net.ssl.trustStorePassword", "changeit");
  //System.setProperty("javax.net.debug", "all");

  // for localhost testing only
  javax.net.ssl.HttpsURLConnection.setDefaultHostnameVerifier(new javax.net.ssl.HostnameVerifier() {
        public boolean verify(String hostname, javax.net.ssl.SSLSession sslSession) {
          return hostname.equals("localhost");
        }

  });
}

1

Mein Problem war, dass ein Cloud Access Security Broker, NetSkope, durch ein Software-Update auf meinem Arbeitslaptop installiert wurde. Dies veränderte die Zertifikatkette und ich konnte nach dem Importieren der gesamten Kette in meinen Cacerts-Keystore immer noch keine Verbindung zum Server über meinen Java-Client herstellen. Ich habe NetSkope deaktiviert und konnte erfolgreich eine Verbindung herstellen.


1

In meinem Fall war ich mit dem Problem konfrontiert, weil in meinem Tomcat-Prozess ein spezifischer Keystore mit verwendet wurde

-Djavax.net.ssl.trustStore=/pathtosomeselfsignedstore/truststore.jks

Während ich das Zertifikat in das Zertifikat von JRE / lib / security importierte und die Änderungen nicht widerspiegelten. Dann habe ich den folgenden Befehl ausgeführt, wobei /tmp/cert1.test das Zertifikat des Zielservers enthält

keytool -import -trustcacerts -keystore /pathtosomeselfsignedstore/truststore.jks -storepass password123 -noprompt -alias rapidssl-myserver -file /tmp/cert1.test

Wir können überprüfen, ob der Zertifikatimport erfolgreich ist

keytool -list -v -keystore /pathtosomeselfsignedstore/truststore.jks

und prüfen Sie, ob Ihr Taget-Server gegen den Alias ​​rapidssl-myserver gefunden wurde


0

Überprüfen Sie, ob die Datei $JAVA_HOME/lib/security/cacertsexistiert! In meinem Fall war es keine Datei, sondern ein Link zu /etc/ssl/certs/java/cacertsund auch dies war ein Link zu sich selbst (WAS ???), sodass JVM die Datei aufgrund dessen nicht finden kann.

Lösung: Kopieren Sie die echte Cacerts-Datei ( Sie können dies von einem anderen JDK aus tun ) in ein /etc/ssl/certs/java/Verzeichnis und es wird Ihr Problem lösen :)


In der Tat unterhält JDK eine Verknüpfung und möglicherweise aus Gründen der Kompatibilität mit älteren APIs, SDKs ... Ich habe es erfolgreich geschafft ... Ich wechsle von JDK 8 zu JDK 10 und verwende Docker, sodass ich nur die Cacerts von einem kopieren musste Bild zu einem anderen ... Ich habe den Link erstellt und genau so ...rm -f /opt/jdk-minimal/jre/lib/security/cacerts ; ln -s /etc/ssl/certs/java/cacerts /opt/jdk-minimal/jre/lib/security/cacerts
Marcello de Sales

-9

Nehmen wir an, Sie verwenden Klassenpfadvariablen wie $ {JAVA_HOME} in pom.xml.

<target>
                    <property name="compile_classpath" refid="maven.compile.classpath"/>
                    <property name="runtime_classpath" refid="maven.runtime.classpath"/>
                    <property name="test_classpath" refid="maven.test.classpath"/>
                    <property name="plugin_classpath" refid="maven.plugin.classpath"/>
                    <property name="jaxb-api.jar" value="${maven.dependency.javax.xml.bind.jaxb-api.jar.path}"/>
                    <property name="project_home" value="${PROJECT_HOME}"/>
                    <property name="java_home" value="${JAVA_HOME}"/>
                    <property name="ant_home" value="${ANT_HOME}"/>
                    <property name="common_home" value="${COMMON_HOME}"/>
                    <property name="JAXP_HOME" value="${common_home}/lib"/>
                    <property name="ejfw_home" value="${PROJECT_HOME}/lib"/>
                    <property name="weblogic_home" value="${WL_HOME}"/>
                    <property name="fw_home" value="${FW_HOME}"/>
                    <property name="env" value="${BUILDENV}"/>
                    <property name="tokenfile" value="${BUILDENV}${BUILDENV_S2S}.properties"/>

Fügen Sie für Ziele die Klassenpfadvariablen hinzu. dh .., -DANT_HOME, -DJAVA_HOME

clean install -e -DPROJECT_HOME=..... -DANT_HOME=C:\bea1036\modules\org.apache.ant_1.7.1 -DJAVA_HOME=C:\bea1036\jdk160_31

1
Klassenpfade und Zertifikate haben überhaupt nichts miteinander zu tun.
Marquis von Lorne

1
Ich glaube, Sie haben die Frage falsch verstanden.
Dawood ibn Kareem
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.