My database admin told me that a secure handshake of SSL credentials is required to connecting the DB2 server.
But they are not familiar with db2cli.exe.
So what is the most simple way to enable my db2cli command to initiate the connection with SSL handshake ?
db2cli is a utility that's included with the IBM DB2 Data Server Driver package. It's generally used for either validating entries in the db2dsdriver.cfg file or registering System ODBC DSNs on Windows machines. The db2dsdriver.cfg file in an XML file that actually contains all of the connection details for each database. db2cli can be used as a debugging utility to call CLI functions, but I can't imagine too many people are using it to type CLI function calls.
So, to enable SSL, you'd either need to modify the db2dsdriver.cfg file to add the appropriate SSL-related options (Security=ssl, SSLClientKeystoredb=/path/to/keystore, SSLClientKeystash=/path/to/keystash) for the particular database. You will also need to create the SSL client keystore/keystash and add your database server's SSL certificate to the keystore.
Alternatively, if you are defining your connections in the application you can specify these options in the DSN you pass to SQLDriverConnect():
"Database=sampledb; Protocol=tcpip; Hostname= myhost; Servicename=50001;
Security=ssl; SSLClientKeystoredb=/home/test1/keystore/clientstore.kdb;
SSLClientKeystash=/home/test1/keystore/clientstore.sth;"
This is documented here.
Related
We are just starting to use google cloud data fusion for our ETL.
We have a use case to hit a server(self-signed) and get some info using the http-plugin in the data fusion product.
In my pipeline, i am turning off SSL verification to accept any certificates but getting an error
javax.net.ssl.SSLPeerUnverifiedException: Certificate for <on000120.aeo.ae.com> doesn't match any of the subject alternative names: []
Help text for the field also suggests to urn it off. See image.
Could someone please help?
I followed the instructions at https://www.freecodecamp.org/news/how-to-get-https-working-on-your-local-development-environment-in-5-minutes-7af615770eec/ to generate the key and crt files, so I had a file called v3.ext (which includes subjectAltName) and used that to generate the server.crt file. When I started my server with these files, I was able to deploy and run a pipeline using HTTP source from that local HTTPS server. How did you generate your crt and key? Would you please describe the plugins you're using?
I assume that issue that you've reported is not connected with Data Fusion runtime environment, but might be supposedly related the target HTTPS web server SSL/TLS configuration. Most of the time this issue occurs when the common name or SAN(Subject Alternative Name) of your SSL/TLS Certificate does not match the domain or address that you hit in HTTP call, hence this page is not listed in SAN's list and I can suppose that you didn't add any of domain names there.
As far as I know Data Fusion http-plugin, which is based on Java HTTP Client implementation, promotes HostnameVerifier class, that is used for URL's hostname and the server's identification hostname verification during establishing handshake between parties, you may take a look at the source code and find inherited method getDefaultHostnameVerifier() as well. Therefore, this can lead to the error, during http client intentions to launch SSL/TLS connection channel.
Even though, you turned of trust keystore certificate inspection in the plugin settings, the issue will persist because hostname validation still failing.
Hi I want to have the ability to connect from jdbc driver to snowflake with ssl. I did it many times with other db, just add ssl=true(sometimes other properties) in connection url.
Unfortunately I didn't find this option in snowflake documentation. I found that snowflake supports something like ssl they call it Using Key Pair Authentication
Does it ssl mode for snowflake?
Does snowflake support ssl?
You can set a jdbc connection property ssl to on or off as seen here
That's what determines if the connection will be made via https or http, going by the implementation here
I tried it and it worked for me.
Note that if ssl is not set, the value is on by default.
I believe Snowflake only allows HTTPS to connect, and so it always uses TLS/SSL.
SSL encryption cannot be switched off when connecting to Snowflake. Full Stop.
There is no option in the JDBC or ODBC driver to disable (or enable) SSL. That is why this parameter is not mentioned on the documentation pages of Snowflake.
Generic
ODBC
Snowflake connections use SSL by default.
And using only HTTPS connections. Regardless whether it is a driver or the GUI.
That is also the reason that you do not need to add https:// to your server connection.
More on this can be found here.
The http-connections you might see Snowflake drivers make are to satisfy OCSP.
If you trying to test whether Snowflake supports un-encrypted connections and you get the information back that Snowflake does support unencrypted connections or does support TLS1.0 or TLS1.1 you have been testing your proxy-server settings and not snowflakecomputing.com or snowflake.com.
BTW : Currently only TLS1.2 is supported by Snowflake for HTTPS connections.
For my current project i need to implement http over tls at client ,for this i need a local server able to simulate this . is there any online or offline tool. which i can use and and see the handshake in wireshark .
For watching the TLS handshake you might not get far enough with wireshark. For such kind of monitoring you would ensure the security is low enough for wireshark to be able getting the session key from watching the handshake for decoding the later parts. Thus, you need to avoid any forward secrecy.
Otherwise any (https) server that is accessible (and willing to talk) to your client will do.
In case you are in an environment that is supported (e.g. any unix/linux), you might try using openssl. It allows setting up a server that will do handshake. And it will log the handshake such that you will be able looking at what is going on. This will eliminate the need for using wireshark for debugging.
For achieving this you need a Web Server accepting connection over TLS.I have achieved this on Apache Tomcat web Server.
TLS configuration needs to be done in the server.xml file present in config directory of Tomcat webserver. Connector tag needs to be added in the server.xml file that contains information like
TLS version to be used, port, List of supported Cipher Suites, Keystore path and password, Truststore path and password.
Any regular Rest client can be used to make a call like Postman client. But to use that over TLS/SSL certificate is needed to be installed in Chrome browser.
Hope this answers your doubt.
I'm pretty far out of my depth here, so bear with me. We're using JDBC via com.intersys.jdbc.cachedriver to run stored procedures in Intersystems Cache and get the results in Java. However, there are other clients that connect directly to the Cache using a terminal over telnet. We have to lock down Cache's telnet port so that only telnet over SSL is possible. However, the Cache experts here say that locking down one port in Cache locks them all down, so the Java to Cache connection will also have to use SSL. I understand vaguely that some JDBC drivers support SSL, but I don't see that the Cache one does. What I need to know is:
What's needed to configure SSL for the JDBC connections? (We're using JBoss 4.2.3)
What about certificates? I assume those have to go somewhere.
Is it actually true that locking down the telnet connections is also going lock down JDBC in the same way?
Configuring Java Clients to Use SSL/TLS with Caché
Using SSL/TLS with Caché
Telnet vs ssh is a question about what the OS allows and only relates to Cache peripherally. It doesn't mean anything regarding items 1 or 2. So in answer to the direct question you are asking, "No".
1. What's needed to configure SSL for the JDBC connections? (We're using JBoss 4.2.3)
See http://docs.intersystems.com/cache20102/csp/docbook/DocBook.UI.Page.cls?KEY=GCAS_ssltls#GCAS_ssltls_javacli for details. This section doesn't explicitly mention JDBC, but it's true for JDBC (and the reference has been added for the documentation 2011.1 [next release] .)
2. What about certificates? I assume those have to go somewhere.
To quote the documentation: "If the client has a private key and certificate, these are stored in the client’s keystore; the keystore can also hold the client’s root CA certificate and any intermediate CA certificates. To authenticate the server, the client may need to have the root CA certificate for the server and any intermediate CA certificates, these can be stored either in the client’s truststore or along with client certificate information in the keystore. For more information on keystores and truststores, see the section “Keystores and Truststores” in the Java Secure Socket Extension (JSSE) Reference Guide."
3. Is it actually true that locking down the telnet connections is also going lock down JDBC in the same way?
Yes -- if telnet connections are to require TLS, then the superserver TLS setting needs to be Required, which means that you have to use TLS for anything that goes through the superserver (including JDBC). If you just want to allow the use of TLS for telnet connections, set the TLS value to Enabled, which allows non-TLS connections by other means (such as JDBC).
All,
I'm trying to configure LDAP with Websphere. I'm doing settings in "Security" area when I click on 'Test settings' I'm getting connection exception (SECJ7340E). The Ip/host are all fine but I'm not able to connect to the server. Have you come across such a situation?? Do you know the solution to this?
I'm using WAS 7.0.
LDAP troubleshooting is not hard.
What LDAP server are you connecting too? Does it have any logging? Can you get an error message from the LDAP server admins? (I.e. If they see a bad bind DN, bad password error etc, then you have a much easier troubleshooting job to do).
I am sure you have the right IP. Now what port should you be connecting too? Clear text is 389, LDAP over SSL is 636, but they might have changed those values for some reason.
Does your LDAP server allow clear text connections at all?
Do you have SSL configured correctly? Generally this means that whatever system you are using, its trusted root keystore should include the public key of the CA that signed the server cert used by the LDAP server. (I.e. Versign, Thwate) Possibly it is using a self signed certificate, in which case you should get an export of the CA that minted its public key to import into your keystore.
Webshpere is Java based, so I imagine it is using the the Java Keystore facility. Use the keytool executable in the Java bin directory to add the trusted root to the keystore WebSphere is using. (That detail I leave to you).
What Bind DN are you using? Is it a real correct LDAP DN to connect with?
Use an LDAP browser like ApacheDS and see what it takes to connect to the LDAP server to validate the settings.