I am trying to connect to a t3 url which I am told has a blank username and password but, I don't know how to pass an empty username and password in the connect() call. How can I do this?
When I do connect('', '', 't3://hostname:port'), WLST tries to connect to the given url using username 'weblogic' which I don't know where it is getting from?
--- UPDATE ---
Please ignore the above... See Sandra's comment.
The script I am trying to run is the one shown in WebLogic Server JMS WLST Script – Who is Connected To My Server. Although I have lightly modified it to pass username, password and url as arguments into the script...
I have saved the script to a file named: listJmsQueueConsumers.py and I run the script as follows:
$ source /opttest/bea/wlserver_10.3/server/bin/setWLSEnv.sh
$ java weblogic.WLST listJmsQueueConsumers.py "username" "password" "t3://ip-address:port" where, the username, password and url are the admin's username, password and url pointing to weblogic server's administrator port.
Now, when I run the script, I get the following error:
Caused by: java.net.ConnectException: t3://ip-address:port: Destination unreachable; nested exception is:
java.net.SocketException: Connection reset; No available router to destination
I have also tries running the script with the same url but using protocol t3s and, when I run the script using t3s, I get:
Caused by: java.net.ConnectException: t3s://ip-address:port: Destination unreachable; nested exception is:
javax.net.ssl.SSLKeyException: [Security:090542]Certificate chain received from bc2-06-v1.compass.cnsonline.net - ip-address was not trusted causing SSL handshake failure. Check the certificate chain to determine if it should be trusted or not. If it should be trusted, then update the client trusted CA configuration to trust the CA certificate that signed the peer certificate chain. If you are connecting to a WLS server that is using demo certificates (the default WLS server behavior), and you want this client to trust demo certificates, then specify -Dweblogic.security.TrustKeyStore=DemoTrust on the command line for this client.; No available router to destination
I am pretty sure the ip address and port I use are the server's ip address and administrator port but I am not sure what the errors actually mean. Do I need some sort of SSL certificate to connect via t3s protocol?
You will need import the certificate from the WebLogic server to the local keystore being used by your local Java client JVM. I use a tool called KeyStore Explorer (http://keystore-explorer.sourceforge.net/) to do this. Other good options are listed here How to properly import a selfsigned certificate into Java keystore that is available to all Java applications by default?
Related
Remote server is an IBM i (7.1) with DB2 installed on it. I am trying to connect to this remote db2 database on IBM i machine via JDBC encrypted link using SSL from my windows machine, I am using jt400-6.7.jar.
I can see that SSL is correctly configured on IBM i machine as I see the following in Digital Certificate Manager :
Current Certificate Store
You have selected to work with the certificate store listed below. The left frame is being refreshed to show the task list for this certificate store. Select a task from the left frame to begin working with this certificate store.
Certificate type: Server or client
Certificate store: *SYSTEM
Certificate store path and filename:
/QIBM/USERDATA/ICSS/CERT/SERVER/DEFAULT.KDB
I followed this link to set up SSL on my IBM i machine :
https://isupport.krengeltech.com/rxs/setting_up_ssl/
This is my JDBC program executed from my windows 10 machine:
import java.sql.*;
public class IBMiSSLConnect
{
public static void main(String[] args) throws Exception
{
try
{
Class.forName("com.ibm.as400.access.AS400JDBCDriver");
Connection con = DriverManager.getConnection("jdbc:as400://IBMiMachineIP:5021/DBNAME&secure=true", "USER", "PASSWORD");
}
catch(Exception e)
{
System.out.println(e.getMessage());
}
}
}
I get the following error :
[PWS0082] library(s) not added to the library list.
If however I replace url as below (adding system library):
Connection con = DriverManager.getConnection("jdbc:as400://IBMiMachineIP:5021/DBNAME;naming=system;libraries=QSYS;secure=true", "USER", "PASSWORD");
I get the following error instead :
The application requester cannot establish the connection. (sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target)
I have two questions:
Q 1: Does one always needs to add naming and libraries in url for JDBC encryption using SSL ?
something like this:
dbc:as400://someserver;naming=system;libraries=devfiles,prodfiles,sysibm,etc
I am refering to this link :
How can I insert additional libraries to my jdbc/DB2 connection?
Q 2: Should I use secure or sslConnection as url parameter ?
that is:
a: jdbc:as400://IBMiMachineIP:5021/DBNAME&secure=true
or
b: jdbc:as400://IBMiMachineIP:5021/DBNAME&sslConnection=true
*Note: I have already made changes to SSL permissions for truststore files default.kdb and default.rdb as mentioned here :
https://isupport.krengeltech.com/rxs/configuring_ssl_permissions/
Q1. No, you do not need to add the naming and libraries properties when using SSL.
Q2. You shouldn't be using the :5021 as part of the URL. It is currently ignored, but may be used in the future. You should be using secure=true to get an SSL connection.
I suspect your problem is that the truststore used by the JVM on the client system does not have the certificate for your Certificate Authority (it looks like you are using a self signed certificate on the server). If you still have problems, turn on SSL trace on the client by using the following when starting java:
-Djavax.net.debug=ssl:handshake:verbose
Note, jt400.jar comes with a jdbcClient, so you can used that to test your connection. Here is an example of connecting using SSL. In this case, the cacerts is the trust store that contains a certificate for the CA that signed the server certificate.
java -Djavax.net.debug=ssl:handshake:verbose -Djavax.net.ssl.trustStore=cacerts -jar jt400.jar 'jdbc:as400:SYSTEM;secure=true' USERID PASSWORD
This will show the SSL negotiation that the JVM is doing.
what #jweberhard said in terms of question, use of library is not required
and ssl port is not 5021 is correct, thanks #jweberhard .However I realized
in my case particularly I was making one wrong assumption based on prior
knowledge .
I have done a similar SSL encrypted connection from windows machine to
remote machines with MySQL DB and Postgres DB and in both cases you see in
wireshark something like this:
1 source IP Dest IP TLSv1.2 220 Client Hello
2 Dest IP source IP TLSv1.2 1140 Server Hello, Certificate, Server Key Exchange, Server Hello Done
3 source IP Dest IP TLSv1.2 129 Client Key Exchange
4 source IP Dest IP TLSv1.2 60 Change Cipher Spec
5 source IP Dest IP TLSv1.2 99 Encrypted Handshake Message
I was looking for TLSv1.2 protocol usage in wireshark , but however I
realized that specially when you are working with DB2 database on IBM i you
would still see TCP protocol being used,
but the litmus test is if you see :
1: Port 9471 being used for SSL Connection in wireshark ( if it is not
secure you will see port 8471 being used instead).
Refer this link for port usage for IBM i :
https://www-03.ibm.com/systems/power/software/i/toolbox/faq/ports.html
and
2: QZDASSINIT job being created on your IBM i machine( Use green screen to
check your job by using WRKACTJOB command and check for this job , this job
is created for SSL connection to your DB2 database , else you would see
only QZDASONIT job which is for a non-secure connection.
I am using a Docker container to run a bunch of services, all of those services make use of certificates to communicate to each other.
When starting up those services there is one in concrete that complains with the following error
> discovery_1 | INFO ttn: Got public keys for token validation
> discovery_1 | DEBUG Connected to gRPC server Address=localhost:1900
> discovery_1 | FATAL Could not start client for gRPC proxy error=x509: certificate is valid for discovery, not localhost
> ttnbackbone_discovery_1 exited with code 1
I have created the certificate for "discovery" user but still Docker runs it for the localhost, in some way, which I don't understand... I have also followed this tutorial of certificates usage from Docker but still I have the same error.
What can I do further?
THanks in advance,
REgards!
I encountered this today. x509 certificates have a Common Name attribute that some software use to match the DNS hostname of a server. Here was my error with a certificate with CN of localhost and a DNS hostname of docker1-staging:
error during connect: Get https://docker1-staging:2376/v1.26/containers/json: x509: certificate is valid for localhost, not docker1-staging
I'll have to regenerate the certificate used by the Docker server and make sure it has a CN value of docker1-staging. You'll have to do the same with a CN value of localhost.
Hello i have istalled to openfire into my computer.I am trying to login to spark using username password and ip address as domain but i am getting I am getting certificate hostname verification failed errror.I found that that they are asking to change server i tried that option as well no result.
When we install Openfire server, it generates self-signed certificates for SSL connections. Now if you are in development phase, you don't need to worry about this error. However, once you go into production, you might consider placing proper HTTPS certificates against your domain.
Certificate directory: OPENFIRE_HOME/resources/security/
During the testing of the Travelocity sample application at Login screen, option2 OpenID, I get the following error at the client side:
0x704: I/O transport error: peer not authenticated
Any recommendation about the required steps to activate SSL protocol
support in the Travelocity sample application running under the Tomcat7?
More details from the Tomcat7 log:
SEVERE: Servlet.service() for servlet [ForwardingServlet] in context with path [/travelocity.com] threw exception [0x704: I/O transport error: peer not authenticated] with root cause
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at com.ibm.jsse2.ab.getPeerCertificates(ab.java:61)
at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
at ...
Thanks for assistance.
As WSO2IS contains a self-signed certificate by default, So you need to configure its certificate as a trusted certificate to the sample application. We can configure a truststore file for the Tomcat server. you can add following two java parameters in to the "catalina.sh" file in /bin directory.
export JAVA_OPTS="-Djavax.net.ssl.trustStore=<PATH_TO_TRUST_STORE_FILE> -Djavax.net.ssl.trustStorePassword=<PASSWORD>"
As an example. Please note that the PATH_TO_TRUST_STORE_FILE file must contains the WSO2 server's certificate.
If your WSO2 server's certificate's CN value is not equal to the WSO2 Server's hostname, you would be probably hit by following error as well
hostname in certificate didn't match: !=. So, you need to make sure CN is equal to hostname as well.
We have IBM Sterling Connect Direct 4.2 on Windows 2003 Server, everything is working fine, even the SSL Configuration, we exchange files properly. Now, I have migrated all the configuration to a Windows Server 2008 cluster environment. Everything it's ok... I have configured the IBM Sterling Connect Direct 4.6.0.1 -even the SSL Configuration, we just have made a copy/paste of the certificates, keycerts and trusted files-. Everything it's ok and we are able to receive files under a SSL session. But... there is an exception.. The problem we are facing is when we try to send files to our partners we get this error:
Message ID: CSPA311E
SSL Certificate verification failed, reason= self certificate in certificate chain:
Followed by this error:
Message ID: CSPA309E
SSL3_GET_SERVER_CERTIFICATE certificate verify failed:
We are using exactly the same configuration, except by the IP and server name, that have changed. The certificates in any way are linked to the server name or the IP?
Any hint on this issue is very appreciated.
A certificate is issued for a specific domain name or IP address. I'm pretty sure that this is the reason for your error. You can check this with keytool.exe which is shipped with a JRE or JDK installation and is located in the /bin directory. So issue the following from your command line:
keytool.exe -printcert -file C:\path\to\your\file.crt
This will give an output like:
In the second line there you can see: Owner: CN=localhost, ... which means that this certificate is issued for localhost.
If this CN entry differs from new the IP address or domain name, you have two possibilities.
Crate a new certificate which is issued for that specific IP or domain. You can use the java keytool.exe again.
You need to update your client application which checks the validity of the certificate. Thereby you need to tell the client to don't check the certs CN name against the real IP address or damain name of the remote server. (Not recommended because of security reasons.)