I have a Java client trying to access a server with a self-signed certificate.
When I try to Post to the server, I get the following error:
unable to find valid certification path to requested target
Having done some research on the issue, I then did the following.
Saved my servers domain name as a root.cer file.
In my Glassfish server's JRE, I ran this:
keytool -import -alias example -keystore cacerts -file root.cer
To check the cert was added to my cacert successfully, I did this:
keytool -list -v -keystore cacerts
I can see the cert is present.
I then restarted Glassfish and retried the 'post'.
I am still getting the same error.
I have a feeling this is because my Glassfish is not actually reading the cacert file that I have amended but maybe some other one.
Have any of you had this issue and can push me in the right direction?
Unfortunately - it could be many things - and lots of app servers and other java 'wrappers' are prone to play with properties and their 'own' take on keychains and what not. So it may be looking at something totally different.
Short of truss-ing - I'd try:
java -Djavax.net.debug=all -Djavax.net.ssl.trustStore=trustStore ...
to see if that helps. Instead of 'all' one can also set it to 'ssl', key manager and trust manager - which may help in your case. Setting it to 'help' will list something like below on most platforms.
Regardless - do make sure you fully understand the difference between the keystore (in which you have the private key and cert you prove your own identity with) and the trust store (which determines who you trust) - and the fact that your own identity also has a 'chain' of trust to the root - which is separate from any chain to a root you need to figure out 'who' you trust.
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
Source: # See http://download.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#Debug
Here is the solution , follow the below link Step by Step :
http://www.mkyong.com/webservices/jax-ws/suncertpathbuilderexception-unable-to-find-valid-certification-path-to-requested-target/
JAVA FILE : which is missing from the 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);
}
}
}
You need to configuring JSSE System Properties, specifically point to client certificate store.
Via command line:
java -Djavax.net.ssl.trustStore=truststores/client.ts com.progress.Client
or 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);
...
For more refer to details on RedHat site.
(repost from my other response)
Use cli utility keytool from java software distribution for import (and trust!) needed certificates
Sample:
From cli change dir to jre\bin
Check keystore (file found in jre\bin directory)
keytool -list -keystore ..\lib\security\cacerts
Password is changeit
Download and save all certificates in chain from needed server.
Add certificates (before need to remove "read-only" attribute on file ..\lib\security\cacerts), run:
keytool -alias REPLACE_TO_ANY_UNIQ_NAME -import -keystore.\lib\security\cacerts -file "r:\root.crt"
accidentally I found such a simple tip.
Other solutions require the use of InstallCert.Java and JDK
source: http://www.java-samples.com/showtutorial.php?tutorialid=210
I had the same problem with sbt.
It tried to fetch dependencies from repo1.maven.org over ssl
but said it was "unable to find valid certification path to requested target url".
so I followed this post
and still failed to verify a connection.
So I read about it and found that the root cert is not enough, as was suggested by the post,so - the thing that worked for me was importing the intermediate CA certificates into the keystore.
I actually added all the certificates in the chain and it worked like a charm.
I came across this error while trying to access a https url from my application which was using self-signed certificate.
What they provide is a .cert file and I was not sure where to put that. I solved it the following way:
keytool location is under JDK/bin folder
Method 1: Add the certificate to default Java Truststore - cacerts:
keytool -import -alias myCert -file C://certificate.cert -keystore C://Program Files//Java//jdk1.8.0_271//jre//lib//security//cacerts
Password: changeit
Method 2:
Create a Trust Store:
keytool -import -alias myCert -file C://certificate.cert -keystore myTrustStore
It gives you the following prompts, which can be filled up as:
Enter keystore password:changeit
Re-enter new password:changeit
Trust this certificate?yes
This will create a myTrustStore file inside a folder where you ran this command.
Copy this "mytrustStore" to a convenient location.
Use the Trust Store:
While you are running your application/server pass these JVM arguments:
-Djavax.net.ssl.trustStore=C://myTrustStore -Djavax.net.ssl.trustStorePassword=changeit
Solution when migrating from JDK 8 to JDK 10
The certificates are really different
JDK 10 has 80, while JDK 8 has 151
JDK 10 has been recently added the certs
https://dzone.com/articles/openjdk-10-now-includes-root-ca-certificates
http://openjdk.java.net/jeps/319
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
Steps to fix
I deleted the JDK 10 cert and replaced it with the JDK 8
Since I'm building Docker Images, I could quickly do that using Multi-stage builds
I'm building a minimal JRE using jlink as /opt/jdk/bin/jlink \
--module-path /opt/jdk/jmods...
So, here's the different paths and the sequence of the commands...
# 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
I am working on a tutorial for REST web services at www.udemy.com (REST Java Web Services). The example in the tutorial said that in order to have SSL, we must have a folder called "trust_store" in my eclipse "client" project that should contain a "key store" file (we had a "client" project to call the service, and "service" project that contained the REST web service - 2 projects in the same eclipse workspace, one the client, the other the service). To keep things simple, they said to copy "keystore.jks" from the glassfish app server (glassfish\domains\domain1\config\keystore.jks) we are using and put it into this "trust_store" folder that they had me make in the client project. That seems to make sense: the self-signed certs in the server's key_store would correspond to the certs in the client trust_store. Now, doing this, I was getting the error that the original post mentions. I have googled this and read that the error is due to the "keystore.jks" file on the client not containing a trusted/signed certificate, that the certificate it finds is self-signed.
To keep things clear, let me say that as I understand it, the "keystore.jks" contains self-signed certs, and the "cacerts.jks" file contains CA certs (signed by the CA). The "keystore.jks" is the "keystore" and the "cacerts.jks" is the "trust store". As "Bruno", a commenter, says above, "keystore.jks" is local, and "cacerts.jks" is for remote clients.
So, I said to myself, hey, glassfish also has the "cacerts.jks" file, which is glassfish's trust_store file. cacerts.jsk is supposed to contain CA certificates. And apparently I need my trust_store folder to contain a key store file that has at least one CA certificate. So, I tried putting the "cacerts.jks" file in the "trust_store" folder I had made, on my client project, and changing the VM properties to point to "cacerts.jks" instead of "keystore.jks". That got rid of the error. I guess all it needed was a CA cert to work.
This may not be ideal for production, or even for development beyond just getting something to work. For instance you could probably use "keytool" command to add CA certs to the "keystore.jks" file in the client. But anyway hopefully this at least narrows down the possible scenarios that could be going on here to cause the error.
ALSO: my approach seemed to be useful for the client (server cert added to client trust_store), it looks like the comments above to resolve the original post are useful for the server (client cert added to server trust_store). Cheers.
Eclipse project setup:
MyClientProject
src
test
JRE System Library
...
trust_store
---cacerts.jks
---keystore.jks
Snippet from MyClientProject.java file:
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");
}
});
}
Wasted a lot of time on that issue. If you imported the certificate and you can see it listed here.
keytool -list -v -keystore $JAVA_HOME/lib/security/cacerts
Then create the new one, with the following command, replace SITE_NAME, SITE_PORT, CERTIFICATE_NAME and path to save file.
echo -n | openssl s_client -connect SITE_NAME:SITE_PORT \
| openssl x509 > /path/to/save/CERTIFICATE_NAME.cert
In my case, I experienced problem using Keycloak with Spring. After I created certificate with this command and imported to keystore, the problem was solved and it works fine
My problem was that a Cloud Access Security Broker, NetSkope, was installed on my work laptop through a software update. This was altering the certificate chain and I was still not able to connect to the server through my java client after importing the entire chain to my cacerts keystore. I disabled NetSkope and was able to successfully connect.
Check if the file $JAVA_HOME/lib/security/cacerts exists!
In my case it was not a file but a link to /etc/ssl/certs/java/cacerts and also this was a link to itself (WHAT???) so due to it JVM can't find the file.
Solution:
Copy the real cacerts file (you can do it from another JDK) to /etc/ssl/certs/java/ directory and it'll solve your problem :)
note for eclipse / Sts users:
Because eclipse uses its own JRE, you should add certs to its own JRE keystore.
I had this issue until I added certs to Sts's JRE.
SSL log:
`javax.net.ssl|DEBUG|1A|restartedMain|2021-12-06 23:04:00.874` IRST|TrustStoreManager.java:113|trustStore is: D:\sts-4.12.0.RELEASE\plugins\org.eclipse.justj.openjdk.hotspot.jre.full.win32.x86_64_16.0.2.v20210721-1149\jre\lib\security\cacerts
This is the full path: "sts-4.12.0.RELEASE\plugins\org.eclipse.justj.openjdk.hotspot.jre.full.win32.x86_64_16.0.2.v20210721-1149\jre\lib\security\cacerts"
In my case I was facing the problem because in my tomcat process specific keystore was given using
-Djavax.net.ssl.trustStore=/pathtosomeselfsignedstore/truststore.jks
Wheras I was importing the certificate to the cacert of JRE/lib/security and the changes were not reflecting.
Then I did below command where /tmp/cert1.test contains the certificate of the target server
keytool -import -trustcacerts -keystore /pathtosomeselfsignedstore/truststore.jks -storepass password123 -noprompt -alias rapidssl-myserver -file /tmp/cert1.test
We can double check if the certificate import is successful
keytool -list -v -keystore /pathtosomeselfsignedstore/truststore.jks
and see if your taget server is found against alias rapidssl-myserver
In my case, I was getting error connecting to AWS Gov Postgres RDS. There is a separate link for GOV RDS CA certs- https://s3.us-gov-west-1.amazonaws.com/rds-downloads/rds-combined-ca-us-gov-bundle.pem
Add this pem certs to cacerts of java. You can use below script.
------WINDOWDS STEPS-------
Use VSCODE editor and install openssl, keytool plugins
create a dir in C:/rds-ca
place 'cacerts' file and below script file - 'addCerts.sh' inside dir 'rd-ca'
run from vscode:
4.1 cd /c/rds-ca/
4.2 ./addCerts.sh
Copy cacerts to ${JAVA_HOME}/jre/lib/security
Script code:
#!/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"
SSL mode
Happened to me because my config included sslmode=verify-full. You may need to change this to sslmode=require. Or a programatic equivalent of that.
This also applies to using SSL/TLS from applications.
For instance, a Database client in IntelliJ IDEA's. There you need to go to the connection properties, SSH/SSL tab, and set Mode to Require.
More about SSL/TLS modes e.g here: https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes/
I created a ubuntu on my windows 10 laptop and I ran into issue when I was trying to load CMAK site download from https://github.com/yahoo/CMAK site. First it gave fatal ssl error.
openssl s_client -showcerts -servername github.com -connect github.com:443 </dev/null 2>/dev/null | sed -n -e '/BEGIN\ CERTIFICATE/,/END\ CERTIFICATE/ p' > github-com.pem
and use the following command (make sure you put right path for ca-cert)
cat github-com.pem | sudo tee -a /etc/ssl/certs/ca-certificates.crt
Then use the following statement (make sure the path for cert is correct):
git config --global http.sslCAinfo /etc/ssl/certs/ca-certificates.crt
Then I was able to download CMAK but ran into issue when i tried ./sbt clean statement. It was giving a pkix path error. The reason is that I do not have my company issue cert stored in my cacert file.
I have downloaded the company cert (google on how to do it) and followed this article to add my downloaded cert to cacert file. Used sudo update-ca-certificates one more time before ./sbt. It worked for me.
Note: You may have to switch between root and exit when you are following above steps.
This is what I did.
I wanted to develop the app on Java 10, and I had the Eclipse IDE 2020-06.
The cert import solution did not work for me.
So then I installed Java 11 JDK, switched to the latest Eclipse IDE (which runs on Java 11), and made sure that the source-code still gets compiled against the Java 10, by adding these statemements under Maven POM:
<maven.compiler.target>1.10</maven.compiler.target>
<maven.compiler.source>1.10</maven.compiler.source>
<maven.compiler.release>10</maven.compiler.release>
And it works like a charm; no errors.
I'm running a java program where I transfer a file from one folder to another, using Java SFTP. The problem I'm having is that I'm getting the following error in my Java SFTP (using JSch) :
C:\Oracle\Middleware\Oracle_Home\oracle_common\jdk\bin\javaw.exe
-server -classpath C:\JDeveloper\mywork\Java_Hello_World.adf;C:\JDeveloper\mywork\Java_Hello_World\Client\classes;C:\Users\ADMIN\Downloads\jsch-0.1.53.jar
-Djavax.net.ssl.trustStore=C:\Users\IBM_AD~1\AppData\Local\Temp\trustStore5840796204189742395.jks
FileTransfer com.jcraft.jsch.JSchException: UnknownHostKey: 127.0.0.1.
RSA key fingerprint is a2:39:3f:44:88:e9:1f:d7:d1:71:f4:85:98:fb:90:dc
at com.jcraft.jsch.Session.checkHost(Session.java:797) at
com.jcraft.jsch.Session.connect(Session.java:342) at
com.jcraft.jsch.Session.connect(Session.java:183) at
FileTransfer.main(FileTransfer.java:33) Process exited with exit code
0.
The following is my code so far:
FileTransfer fileTransfer = new FileTransfer();
JSch jsch = new JSch();
try {
String host = "127.0.0.1";
int port = 22;
String user = "user";
Session session = jsch.getSession(user, host, port);
session = jsch.getSession("username", "127.0.0.1", 22);
session.connect(); // bug here , java.net.ConnectException
ChannelSftp sftp = null;
sftp = (ChannelSftp)session.openChannel("sftp") ; //channel;
//extra config code
java.util.Properties config = new java.util.Properties();
config.put("StrictHostKeyChecking", "no");
session.setConfig(config);
// end extra config code
sftp.rename("C:\\Users\\ADMIN\\Desktop\\Work\\ConnectOne_Bancorp\\Java_Work\\SFTP_1\\house.bmp", "C:\\Users\\ADMIN\\Desktop\\Work\\ConnectOne_Bancorp\\Java_Work\\SFTP_2\\house.bmp");
session.disconnect();
} catch (JSchException e) {
e.printStackTrace();
} catch (SftpException e) {
e.printStackTrace();
} //end-catch
My Cygwin is set up, and I checked (with netstat -a -b ) that it's running.
You are trying to skip a host key checking by setting StrictHostKeyChecking to no.
But you have to do that before the checking, i.e. before the session.connect().
Anyway, you should never do this, unless you do not care about security. The host key checking is there to protect you from man-in-the-middle attacks.
Instead, set up an expected host key to let JSch verify it.
For example:
Call JSch.setKnownHosts providing a path to a .ssh/known_hosts-like file.
To generate the .ssh/known_hosts-like file, you can use an ssh-keyscan command from OpenSSH. If you are connecting from a *nix server, you should have the command available, just run
ssh-keyscan example.com > known_hosts
It will have a format like:
example.com ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA0hVqZOvZ7yWgie9OHdTORJVI5fJJoH1yEGamAd5G3werH0z7e9ybtq1mGUeRkJtea7bzru0ISR0EZ9HIONoGYrDmI7S+BiwpDBUKjva4mAsvzzvsy6Ogy/apkxm6Kbcml8u4wjxaOw3NKzKqeBvR3pc+nQVA+SJUZq8D2XBRd4EDUFXeLzwqwen9G7gSLGB1hJkSuRtGRfOHbLUuCKNR8RV82i3JvlSnAwb3MwN0m3WGdlJA8J+5YAg4e6JgSKrsCObZK7W1R6iuyuH1zA+dtAHyDyYVHB4FnYZPL0hgz2PSb9c+iDEiFcT/lT4/dQ+kRW6DYn66lS8peS8zCJ9CSQ==
And reference the generated known_hosts file in your JSch code.
If you are on Windows, you can get a Windows build of ssh-keyscan from Win32-OpenSSH project or Git for Windows.
Call JSch.getHostKeyRepository().add() to provide the expected host key (e.g. hard-coded, as your other credentials).
See Creating JSch HostKey instance from a public key in .pub format.
jsch version : 0.1.55
my problem solved by running :
ssh-keyscan -t rsa <HOST_NAME> >> ~/.ssh/known_hosts
ssh-keyscan -t rsa <IP_ADDRESS_OF_HOST_NAME> >> ~/.ssh/known_hosts
**in my case jsch was looking for ip address in known_hosts file
jsch.setKnownHosts(System.getProperty("user.home")+"/.ssh/known_hosts");
Aside: by "Cygwin" I assume you mean sshd or sftpd, because Cygwin itself doesn't do SSH.
Anyway, if you want Jsch client to accept any key from the host, move the .setConfig calls that sets StrictHostKeyChecking no so it is before session.connect(). Alternatively you must provide access to a store containing the correct key(s) for your hosts(s) as #Martin explains -- and you should always do that when connecting to anything other than "localhost" or possibly a machine certain to be on the same, physically-secure network segment (such as a wired LAN hub within a single room).
I'm looking to parse an XML file that updates said file daily - the only issue I've run into is that they use their own certificate (https://...) and I can't use that specific URL, nor is there an http://... link available.
URL url = new URL("https://...");
...
Document document = db.parse(url.openStream());
This code throws the following exception while running my tests:
javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
I've seen a variety of suggestions dealing with creating various classes to deal with this kind of connection or with a personal server, as well as adding the certificate to a keystore and then adding that keystore to the Java project, but I've been unable to do that and am looking for a slightly simpler way for me to go about accessing the XML online.
You need a truststore to store SSL certificates. You can download the certificate using your preferred web browser. To load the certificate into the truststore, you need the "keytool" program, which comes with the JDK.
For example, if your certificate file is named "certificate.crt" and you want to create a truststore named "secure.ts", you can invoke keytool as follows:
keytool -importcert -keystore secure.ts -storepass S3cuR3pas$! -file certificate.crt
Now, you must tell your program where the keystore is and the password to open it, defining the system properties "javax.net.ssl.trustStore" and "javax.net.ssl.trustStorePassword" before opening the connection
URL url = new URL("https://...");
System.setProperty("javax.net.ssl.trustStore", "secure.ts");
System.setProperty("javax.net.ssl.trustStorePassword", "S3cuR3pas$!");
...
Document document = db.parse(url.openStream());
This curious message means the truststore wasn't found.
Nothing whatsoever to do with XML BTW.
You can try with this:
String javaHomePath = System.getProperty("java.home");
String keystore = javaHomePath + "/lib/security/cacerts";
String storepass= "changeit";
String storetype= "JKS";
String[][] props = {
{ "javax.net.ssl.trustStore", keystore, },
{ "javax.net.ssl.keyStore", keystore, },
{ "javax.net.ssl.keyStorePassword", storepass, },
{ "javax.net.ssl.keyStoreType", storetype, },
};
for (int i = 0; i < props.length; i++) {
System.getProperties().setProperty(props[i][0], props[i][1]);
}
// Now you can proceed to connect to call the webservice.
// SSL will be used automatically if the service endpoint url
// starts with https://.
// The server will send its certificate signed by verisign and
// client will trust and authenticate the server as it recognizes
// verisign as one trusted root.
I ran into the same Exception for my MAC OSX (Yosemite), while developing Java 6 applications. You need to download and install Apple's Java for OSX 2014:
http://support.apple.com/kb/DL1572