Ik heb een Java-client die toegang probeert te krijgen tot een server met een zelfondertekend certificaat.
Als ik probeer te posten op de server, krijg ik de volgende foutmelding:
kan geen geldig certificeringspad vinden naar het gevraagde doel
Na wat onderzoek naar het probleem te hebben gedaan, heb ik het volgende gedaan.
- De domeinnaam van mijn server opgeslagen als een
root.cer-bestand. - In de JRE van mijn Glassfish-server heb ik dit uitgevoerd:
keytool -import -alias example -keystore cacerts -file root.cer - Om te controleren of het certificaat succesvol aan mijn cacert is toegevoegd, heb ik dit gedaan:
keytool -list -v -keystore cacerts
Ik zie dat het certificaat aanwezig is. - Ik heb toen Glassfish opnieuw opgestart en de ‘post’ verwijderd.
Ik krijg nog steeds dezelfde foutmelding.
Ik heb het gevoel dat dit komt omdat mijn Glassfish niet het cacert-bestand leest dat ik heb gewijzigd, maar misschien een ander.
Heeft iemand van jullie dit probleem gehad en kan me in de goede richting duwen?
Antwoord 1, autoriteit 100%
Helaas – het kan van alles zijn – en veel app-servers en andere Java-‘wrappers’ zijn geneigd te spelen met eigenschappen en hun ‘eigen’ kijk op sleutelhangers en wat al niet. Het kan dus zijn dat het naar iets heel anders kijkt.
Kort aan truss-ing – ik zou het proberen:
java -Djavax.net.debug=all -Djavax.net.ssl.trustStore=trustStore ...
om te kijken of dat helpt. In plaats van ‘alle’ kan men het ook instellen op ‘ssl’, key manager en trust manager – wat in jouw geval kan helpen. Als u dit op ‘help’ instelt, wordt er op de meeste platforms zoiets als hieronder weergegeven.
Ongeacht – zorg ervoor dat u volledig het verschil begrijpt tussen de keystore (waarin u de privésleutel en het certificaat waarmee u uw eigen identiteit bewijst) en de truststore (die bepaalt wie u vertrouwt) – en het feit dat uw eigen identiteit heeft ook een ‘keten’ van vertrouwen naar de root – die los staat van elke keten naar een root die je nodig hebt om erachter te komen ‘wie’ je vertrouwt.
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
Bron: # Zie http: //download.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#Debug
Antwoord 2, autoriteit 13%
Hier is de oplossing, volg de onderstaande link Stap voor stap:
JAVA-BESTAND: dat ontbreekt op de blog
/*
* 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);
}
}
}
Antwoord 3, autoriteit 8%
U moet JSSE-systeemeigenschappen configureren, specifiek verwijzen naar het clientcertificaatarchief.
Via opdrachtregel:
java -Djavax.net.ssl.trustStore=truststores/client.ts com.progress.Client
of via 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);
...
Raadpleeg voor meer informatie over RedHat-site.
Antwoord 4, autoriteit 7%
(repost van mijn andere reactie)
Gebruik cli utility keytool van java softwaredistributie voor import (en trust!) benodigde certificaten
Voorbeeld:
-
Van cli verander dir naar jre\bin
-
Controleer keystore (bestand gevonden in jre\bin directory)
keytool -list -keystore ..\lib\security\cacerts
Wachtwoord is wijzigen -
Download en bewaar alle certificaten in de keten van de benodigde server.
-
Voeg certificaten toe (voordat u het “alleen-lezen”-kenmerk uit bestand
..\lib\security\cacertsmoet verwijderen), voer het volgende uit:keytool -alias REPLACE_TO_ANY_UNIQ_NAME -import -keystore.\lib\security\cacerts -file "r:\root.crt"
per ongeluk vond ik zo’n simpele tip.
Andere oplossingen vereisen het gebruik van InstallCert.Java en JDK
bron: http://www.java-samples.com/showtutorial .php?tutorialid=210
Antwoord 5, autoriteit 4%
Ik had hetzelfde probleem met sbt.
Het probeerde afhankelijkheden op te halen van repo1.maven.org via ssl
maar zei dat het “geen geldig certificeringspad naar de gevraagde doel-url kon vinden”.
dus ik volgde dit bericht
en het is nog steeds niet gelukt om een verbinding te verifiëren.
Dus ik las erover en ontdekte dat het rootcertificaat niet genoeg is, zoals werd gesuggereerd door de post, dus –
het ding dat voor mij werkte, was het importeren van de tussenliggende CA-certificaten in de keystore .
Ik heb eigenlijk alle certificaten in de keten toegevoegd en het werkte als een tierelier.
Antwoord 6, autoriteit 2%
Oplossing bij migratie van JDK 8 naar JDK 10
- De certificaten zijn echt anders
- JDK 10 heeft 80, terwijl JDK 8 151 heeft
- JDK 10 is onlangs toegevoegd aan de
certs
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
Stappen om op te lossen
- Ik heb het JDK 10-certificaat verwijderd en vervangen door het JDK 8
- Aangezien ik Docker-afbeeldingen aan het bouwen ben, zou ik dat snel kunnen doen met behulp van Multi-stage builds
- Ik bouw een minimale JRE met
jlinkals/opt/jdk/bin/jlink \
--module-path /opt/jdk/jmods...
- Ik bouw een minimale JRE met
Dus, hier zijn de verschillende paden en de volgorde van de opdrachten…
# 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
Antwoord 7, autoriteit 2%
Ik werk aan een zelfstudie voor REST-webservices op www.udemy.com (REST Java Web Services). Het voorbeeld in de tutorial zei dat om SSL te hebben, we een map met de naam “trust_store” in mijn eclipse “client” -project moeten hebben die een “key store” -bestand zou moeten bevatten (we hadden een “client” -project om de service aan te roepen , en “service” -project dat de REST-webservice bevatte – 2 projecten in dezelfde eclipse-werkruimte, de ene de client, de andere de service). Om het simpel te houden, zeiden ze dat we “keystore.jks” moesten kopiëren van de glassfish-app-server (glassfish\domains\domain1\config\keystore.jks) die we gebruiken en het in de map “trust_store” moesten plaatsen die ze me lieten maken het klantproject. Dat lijkt logisch: de zelfondertekende certificaten in de key_store van de server zouden overeenkomen met de certificaten in de trust_store van de client. Nu ik dit deed, kreeg ik de fout die in het oorspronkelijke bericht wordt genoemd. Ik heb dit gegoogled en gelezen dat de fout te wijten is aan het bestand “keystore.jks” op de client dat geen vertrouwd/ondertekend certificaat bevat, en dat het gevonden certificaat zelfondertekend is.
Om alles duidelijk te houden, wil ik zeggen dat zoals ik het begrijp, de “keystore.jks” zelfondertekende certificaten bevat en het bestand “cacerts.jks” CA-certificaten (ondertekend door de CA). De “keystore.jks” is de “keystore” en de “cacerts.jks” is de “trust store”. Zoals “Bruno”, een commentator, hierboven zegt, “keystore.jks” is lokaal en “cacerts.jks” is voor externe clients.
Dus, zei ik tegen mezelf, glassfish heeft ook het bestand “cacerts.jks”, het trust_store-bestand van glassfish. cacerts.jsk zou CA-certificaten moeten bevatten. En blijkbaar heb ik mijn trust_store-map nodig om een sleutelarchiefbestand te bevatten dat ten minste één CA-certificaat heeft. Dus probeerde ik het bestand “cacerts.jks” in de map “trust_store” die ik had gemaakt in mijn klantproject te plaatsen en de VM-eigenschappen te wijzigen om te verwijzen naar “cacerts.jks” in plaats van “keystore.jks”. Dat heeft de fout verholpen. Ik veronderstel dat alles wat nodig was een CA-certificaat was om te werken.
Dit is misschien niet ideaal voor productie, of zelfs niet voor ontwikkeling die verder gaat dan alleen iets laten werken. U kunt bijvoorbeeld waarschijnlijk de opdracht “keytool” gebruiken om CA-certificaten toe te voegen aan het bestand “keystore.jks” in de client. Maar hoe dan ook, hopelijk verkleint dit in ieder geval de mogelijke scenario’s die hier zouden kunnen plaatsvinden om de fout te veroorzaken.
OOK: mijn aanpak leek nuttig voor de client (servercertificaat toegevoegd aan client trust_store), het lijkt erop dat de opmerkingen hierboven om het oorspronkelijke bericht op te lossen nuttig zijn voor de server (clientcertificaat toegevoegd aan server trust_store). Proost.
Eclipse-projectconfiguratie:
- MijnClientProject
- src
- test
- JRE-systeembibliotheek
- …
- trust_store
—cacerts.jks
—keystore.jks
Snippet van MyClientProject.java-bestand:
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");
}
});
}
Antwoord 8
Ik kwam deze fout tegen toen ik probeerde toegang te krijgen tot een https url van mijn applicatie die gebruikmaakte van een zelfondertekend certificaat.
Wat ze bieden is een .cert-bestand en ik wist niet zeker waar ik dat moest plaatsen. Ik heb het op de volgende manier opgelost:
locatie van keytool is onder JDK/bin-map
Methode 1: voeg het certificaat toe aan de standaard Java Truststore – cacerts:
keytool -import -alias myCert -file C://certificate.cert -keystore C://Program Files//Java//jdk1.8.0_271//jre//lib//security//cacerts
Wachtwoord: verander het
Methode 2:
Maak een Trust Store:
keytool -import -alias myCert -file C://certificate.cert -keystore myTrustStore
Het geeft je de volgende prompts, die kunnen worden ingevuld als:
Enter keystore password:changeit
Re-enter new password:changeit
Trust this certificate?yes
Hiermee wordt een myTrustStore-bestand gemaakt in een map waarin u deze opdracht hebt uitgevoerd.
Kopieer deze "mytrustStore" naar een gunstige locatie.
Gebruik de Trust Store:
Terwijl u uw applicatie/server uitvoert, geeft u deze JVM-argumenten door:
-Djavax.net.ssl.trustStore=C://myTrustStore -Djavax.net.ssl.trustStorePassword=changeit
Antwoord 9
Mijn probleem was dat een Cloud Access Security Broker, NetSkope, via een software-update op mijn werklaptop was geïnstalleerd. Dit veranderde de certificaatketen en ik kon nog steeds geen verbinding maken met de server via mijn Java-client nadat ik de hele keten in mijn cacerts-sleutelarchief had geïmporteerd. Ik heb NetSkope uitgeschakeld en kon met succes verbinding maken.
Antwoord 10
Controleer of het bestand $JAVA_HOME/lib/security/cacerts bestaat!
In mijn geval was het geen bestand maar een link naar /etc/ssl/certs/java/cacerts en ook dit was een link naar zichzelf (WAT???), dus daardoor kan JVM’ het bestand niet vinden.
Oplossing:
Kopieer het echte cacerts-bestand (je kunt het doen vanaf een andere JDK) naar de map /etc/ssl/certs/java/ en het zal je probleem oplossen 🙂
Antwoord 11
Ik heb dit toegevoegd aan mijn pom.xml-bestand en het werkte voor mij
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>3.0.0-M5</version>
</plugin>
</plugins>
</build>
Antwoord 12
In mijn geval had ik te maken met het probleem omdat in mijn tomcat-proces een specifieke keystore werd gegeven met
-Djavax.net.ssl.trustStore=/pathtosomeselfsignedstore/truststore.jks
Terwijl ik het certificaat importeerde naar het cacert van JRE/lib/security en de wijzigingen niet werden weergegeven.
Vervolgens deed ik onderstaande opdracht waarbij /tmp/cert1.test het certificaat van de doelserver bevat
keytool -import -trustcacerts -keystore /pathtosomeselfsignedstore/truststore.jks -storepass password123 -noprompt -alias rapidssl-myserver -file /tmp/cert1.test
We kunnen controleren of het importeren van het certificaat is gelukt
keytool -list -v -keystore /pathtosomeselfsignedstore/truststore.jks
en kijk of uw taget-server is gevonden tegen alias rapidssl-myserver
Antwoord 13
In mijn geval kreeg ik een foutmelding bij het verbinden met AWS Gov Postgres RDS. Er is een aparte link voor GOV RDS CA-certificaten – https://s3.us-gov-west-1.amazonaws.com/rds-downloads/rds-combined-ca-us-gov-bundle.pem
Voeg deze pem-certificaten toe aan cacerts van java. U kunt het onderstaande script gebruiken.
——WINDOWDS-STAPPEN——-
- Gebruik de VSCODE-editor en installeer openssl, keytool-plug-ins
- maak een map in C:/rds-ca
- plaats ‘cacerts’-bestand en onder scriptbestand – ‘addCerts.sh’ in dir ‘rd-ca’
- rennen vanuit vscode:
4.1 cd /c/rds-ca/
4.2 ./addCerts.sh - Kopieer cacerts naar ${JAVA_HOME}/jre/lib/security
Scriptcode:
#!/usr/bin/env sh
OLDDIR="$PWD"
CACERTS_FILE=cacerts
cd /c/rds-ca
echo "Downloading RDS certificates..."
curl https://s3.us-gov-west-1.amazonaws.com/rds-downloads/rds-combined-ca-us-gov-bundle.pem > rds-combined-ca-bundle.pem
csplit -sk rds-combined-ca-bundle.pem "/-BEGIN CERTIFICATE-/" "{$(grep -c 'BEGIN CERTIFICATE' rds-combined-ca-bundle.pem | awk '{print $1 - 2}')}"
for CERT in xx*; do
# extract a human-readable alias from the cert
ALIAS=$(openssl x509 -noout -text -in $CERT |
perl -ne 'next unless /Subject:/; s/.*CN=//; print')
echo "importing $ALIAS"
keytool -import \
-keystore $CACERTS_FILE \
-storepass changeit -noprompt \
-alias "$ALIAS" -file $CERT
done
cd "$OLDDIR"
echo "$NEWDIR"