Trying to make Postgres connection to CockroachDB with DataGrip but getting this error:
[08006] The SSLSocketFactory class provided
com.intellij.execution.rmi.ssl.SslSocketFactory could not be
instantiated. signed overrun, bytes = 919.
From the DataGrip connection interface:
URL:
jdbc:postgresql://localhost:26257/postgres
with port 26257 and with SSL enable
CA File
/cert/ca.key
Client Certificate File:
/certs/client.root.crt
Client key file:
/client.root.key
This setup above doesn't work with DataGrip, but the same certs works with the CLI:
cockroach cert create-client root --certs-dir=certs --ca-key=/ca.key
cockroach start --certs-dir=certs --store=node1 --listen-addr=localhost:26257 --http-addr=localhost:8080 --join=localhost:26257,localhost:26258,localhost:26259 --background
What could be wrong with the DataGrip configuration?
I think you need to generate the client cert and key in PKCS8 format for Java. This slightly older version of CockroachDB's Java hello world tutorial has guidance that might help: https://www.cockroachlabs.com/docs/v20.1/build-a-java-app-with-cockroachdb#step-3-generate-a-certificate-for-the-maxroach-user.
Related
I'm using Adempiere 360 ERP solution with Java language, Database PostgreSQL 9.4 and iReport (For reporting) and using CentOS 7 Server. Recently Vendor provide me 4 files about ssl configuration.
But i fail to configure ssl into PostgreSQL 9.4.
I follow some instruction from google but finally fail.
Need proper direction.
What steps are you following?
You have to copy your signed certificate and private key to the required locations on the database server.
Then you just have to edit postgresql.conf
ssl=on
In the pg_hba.conf change the host option to hostssl
hostssl mydb mydbuser 192.168.122.0/24 md5
Then restart your server.
Read this tutorial
Looking for any suggestions connecting with an SSL enabled Cassandra cluster with Datagrip / Intellij / DBVisualizer or any other DB admin tool.
Solution #1
I've tried using the PEM files in the Intellij SSL tab that used for connecting with cqlsh. These do not work. The PEM files do work with cqlsh.
Solution #2
Wondering if there there are some properties to enable SSL. I've tried the following with JKS keystore and Truststore files:
-Djavax.net.ssl.trustStore=
-Djavax.net.ssl.trustStorePassword=
-Djavax.net.ssl.keyStore=
-Djavax.net.ssl.keyStorePassword=
With these properties Intellij / Datagrip does not seem to connect via SSL I feel like a missing property is necessary to enable it.
Connecting with a local non-ssl enable cluster works fine. Any advise would be appreciated with connecting with an SSL enabled cluster.
I am new to elasticsearch and I am following the tutorial here:
I have hit a stumbling block as I can connect the servers with the ELK-stack configured with the server that is logging activity to FileBeat.
I have narrowed it down to an issue with the SSL certificates copied from the ELK server as when i check /var/log/messages I get the following error:
usr/bin/filebeat[13730]: transport.go:125: SSL client failed to
connect with: x509: certificate signed by unknown authority (possibly
because of "crypto/rsa: verification error" while trying to verify
candidate authority certificate "serial:16193853809450343771")
How ever, the keys have been copied over and these files are the same on both servers :
cat /etc/pki/tls/certs/logstash-forwarder.crt
When I try to read the syslogs, I get the following message :
sudo tail /var/log/syslog | grep filebeat:
tail: cannot open ‘/var/log/syslog’ for reading: No such file or directory.
I will appreciate any pointers on this
I found a similar issue in the elastic forum in the following link.
In summery, You should add to your FileBeatconfig:
insecure: true
And than see if you manage to connect. If you do, you can use this guidelines for how to configure your ssl connection
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.
My simple LDAP java program, using
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.SECURITY_AUTHENTICATION, "simple");
env.put(Context.SECURITY_PRINCIPAL, <UserDN>);
env.put(Context.SECURITY_CREDENTIALS, <Password>);
env.put(Context.SECURITY_PROTOCOL, "ssl");
env.put(Context.PROVIDER_URL, "ldaps://<host>:636");
to make LDAP SSL authentication stopped working ever since a 2nd server certificate with the same CN but other details in the subject are different was installed on the server which I don't have access at all.
The program fails when I make the initial context
new InitialDirContext(env);
The error is "Failed to initialize directory context: <host>:636"
It returns the 2nd server certificate when I run
openssl s_client -showcerts -connect <host>:636 </dev/null
that makes me believe that the solution will be to find a way to tell the server which certificate to use.
I search and read a lot of articles on this topic and I have to admit that I am very confused, it is not clear to me if these articles are talking about client certificate or server certificate, or the actions to be taken are for the client side, or server side.
In one article, it says that I can use a custom SSLSocketFactory with the keystore path and
env.put("java.naming.ldap.factory.socket", "com.xxx.MyCustomSSLSocketFactory");
But I don't know the path to the server certificate keystore on the server.
In one Microsoft article, it says the best resolution is to have just one server certificate on the server or to put the server certificate to Active Directory Domain Services (NTDS\Personal) certificate store for LDAPS communications. But I don't have access to the server and the 'fix' to this problem has to be done in my LDAP java program.
In another article, it says to use Server Name Indication (SNI) extension.
So is there a way that I can specify which certificate I want to the server? Or my problem is somewhere else?
Thanks a lot.
Here is the stack trace:
javax.naming.ServiceUnavailableException: <host>:636; socket closed
at com.sun.jndi.ldap.Connection.readReply(Connection.java:419)
at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:340)
at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:192)
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2694)
at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:293)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:175)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:193)
at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:136)
at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:66)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
at javax.naming.InitialContext.init(InitialContext.java:223)
at javax.naming.InitialContext.<init>(InitialContext.java:197)
at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:82)
When I used Jxplorer to run the same test, it gave me the same error.
EJP was right to point out that the issue was that the certificate was not trusted. Many thanks EJP.
When I installed the CA Certificate in %JAVA_HOME%/lib/security/cacerts, Jxplorer worked. My program still failed. I had to add these lines in it to make it work (not sure if I need all of them though ...):
System.setProperty("javax.net.ssl.keyStore",%JAVA_HOME%/lib/security/cacerts);
System.setProperty("javax.net.ssl.trustStore",%JAVA_HOME%/lib/security/cacerts);
System.setProperty("javax.net.ssl.keyStorePassword=changeit);
System.setProperty("javax.net.ssl.trustStorePassword=changeit);
But since the certificate is not trusted in the first place, I simply 'force' our server to trust it, hence this solution is not acceptable. And neither our server nor the LDAP server runs with Java 7. So SNI is out too!
EJP mentioned that I could control the server certificate by restricting the cipher suites or accepted issuers in the client (my webapp), if the server certificates have different algorithms or issuers. The 2 certificates do have different issuers, however, I don't know how to do that and I could not find anything on that neither.
EJP can you please elaborate, or point me to some sites ... ?
If the certificates have different issuers, you can control which certificate you get at the client by controlling which of those issuers is in your truststore. If only one of them is, that's the one you'll get. If they're both there, you get pot luck. Note that if your truststore also contains a common super-issuer, again it's probably pot luck.
The result isn't pot luck if you specify one and only one certificate in the Certificates - Service (Active Directory Domain Service) - NTDS\Personal location in Microsoft Management Console. Contrary to Microsoft docs I've read, though, a domain controller restart seemed to be necessary for the newly specified certificate to 'take hold'.