I have a "blackbox" application written in Java that connects to MQ. On unix server there is MQ Client installation version 7.5.0. Java application is using 1.7.0_79. I have to use SSL_RSA_WITH_AES_256_CBC_SHA256 to make the connection.
I cannot upgrade to MQ Client v8. I am not entirely sure if I can connect having MQ Client version 7.5.0 and for instance use SSL_RSA_WITH_AES_256_CBC_SHA256.
Would be that even possible to establish connection having these components ?
IBM added support for non-IBM Java cipher suite names via APAR IV66840, this was included in MQ v7.5.0.5.
What you are asking should be possible if you have the following:
Set this java system property
-Dcom.ibm.mq.cfg.useIBMCipherMappings=false
or
System.setProperty("com.ibm.mq.cfg.useIBMCipherMappings", "false")
Use cipher suite value TLS_RSA_WITH_AES_256_CBC_SHA256.
Note does not start with SSL_ for Oracle java.
Make sure the strong cryptographic provider is enable in java to support ciphersuites with AES256 encryption. It appears that if you upgrade to a higher level of java 7 (1.7.0_161 for example) this will be included and enabled by default.
Use a JKS keyStore.
Related
We have a WinServer 2019 machine that needs to make REST requests to a third party using TLS1.2 and Cipher Suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. From what I've read, this suite should be enabled by default for this OS version, however, when we make the REST call with Schannel logging enabled I see that it's using CipherSuite: 0xC028 which corresponds to TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (CBC vs GCM). In PowerShell I've tried running Enable-TlsCiphterSuite -Name "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384" -Position 0 and this does add it to the value at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002\Functions. Though, when I run Get-TlsCipherSuite in PowerShell the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 suite that was supposedly enabled does not show up.
Is there another place that needs to be changed in order for this cipher suite to be truly enabled?
The simplest way to achieve this would be downloading a copy of IIS Crypto.
From there you can select the cipher suites tab, enable your chosen cipher and move it to the top as the preferred cipher.
Be aware that some clients may fallback to a weaker cipher if it is available.
When we migrated from .NET framework to .NET core, we had to change the format of our iSeries connection string from using Server= to using Data source= and to include port#, but also we had to include Database= because without it the connection string could not be assigned to a connection due to an "Invalid argument" exception. With absolutely anything for a database, we always get a uniform error message:
ERROR [08004] [IBM] SQL30061N The database alias or database name \"QSYS \" was not found at the remote node.
(Notice extra spaces in the DB name)
No matter what we supply for a database, the error is always the same. We tried our actual library name similar to app0123 that is reported by DSPLIB or QSYS etc.
We also tried databases reported by DSPRDBDIRE named similarly to IHST0123 but in this case the error was different:
ERROR [42968] [IBM] SQL1598N An attempt to connect to the database server failed because of a licensing problem.
We know that there is no licensing problem with the server because it is our production environment that many applications in Java and C# connect to.
Our usual practice is that if an application App1 connects, it uses app1 user name and app01, app02 etc schemas, app01 being the default one. Therefore, we only ever had the iSeries host name like IHST01 etc in the connection string, and we added user ID and password through the connection string builder.
We are having no issues connecting through .NET core connector to DB2 LUW since database on it is very apparent and unambiguous. Since we never had to specify an iSeries database under .NET framework, it is not clear what it has to be. Does anybody know?
The library (aka schema) name is not the database name.
The *LOCAL entry in DSPRDBDIRE should be your DB name.
A better tool is IBM Access Client Soultions (ACS) "Database -->Schemas" tool which has a UI like so:
On the connected server (ut29p63.rch.stglabs.ibm.com), there are (at least) two databases:
ut29p63
Dbtest
I'm surprised you don't think the DB name was needed for .NET Framework or Java as I've always needed them. If you've only got one database on your IBM i, as is common for smaller boxes, it's possible the DB name matches the system name.
Judging from the license error message, you are getting connected.
However, the .NET Core nuget packages use the IBM Db2 Connect driver. This driver is included for Db2 for LUW, and with an appropriate and optional license allows connecting to IBM Db2 for i or IBM Db2 for z/OS.
In other words, the Db2 Connect driver can always connect to Db2 LUW but you'll have to pay for an enhanced license to connect to IBM i or IBM z/OS. See IBM Db2 Connect License Types You'll need an Enterprise license or an Unlimited Edition for System i.
If you were using Db2 Connect driver for your .NET Framework, the same license will work for .NET Core (assuming the Db2 Connect versions match).
However, if you were using the free ODBC/OLEDB/ADO driver for .NET Framework, then you'll need the Db2 Connect license for .NET Core.
I constructed a spring boot application to produce data in a Kafka, but now I need to connect this application to an old Kafka (0.11v). I tried just changing the bootstrap-server, but I receive connection errors.
I doubled checked if this Kafka instance is working, and other applications are connecting.
My question is if a new version of spring-Kafka like v2.5.4.RELEASE can connect to an old version of Kafka. Is there any configuration I can add to use legacy Kafka instances? I constructed a spring boot application to produce data in a Kafka, but now I need to connect this application to an old Kafka (0.11v). I tried just changing the bootstrap-server, but I receive connection errors.
I doubled checked if this Kafka instance is working, and other applications are connecting.
My question is if a new version of spring-Kafka like v2.5.4.RELEASE can connect to an old version of Kafka. Is there any configuration I can add to use legacy Kafka instances?
In general, yes, as long as you don't use features provided by the newer brokers.
Backwards compatibility for the Java clients has been pretty good since 0.10.2.x.
There is a compatibility matrix here but it hasn't been updated since the 1.0.0 clients.
SK v2.5.4 uses the 2.5.0 clients (2.5.5 uses 2.5.1). I haven't tried connecting to such an old broker lately, what is the nature of the connection errors?
EDIT
I just ran a Boot app using Spring Kafka 2.5.5 against an 0.11.0.3 broker with no problems.
I am referring to the line : You can use any standard key tools or Corda’s X509Utilities (which uses Bouncy Castle) to create the required public/private keypairs and certificates. (from https://docs.corda.net/docs/corda-os/3.1/permissioning.html#creating-the-root-and-doorman-cas)
To your questions, you will now need a PKI tool to create the required public/private keypairs and certificates.
However, if I am not mistaken, you are trying to build a private Corda network. Corda 4.5 currently offer 2 toolsets to start a network.
Corda network bootstrapper here. This is for non-production level quick PoC tool. And there is no doorman involved in this toolset. So you actually do not need to worry about the keypair and CA stuff.
Corda Enterprise Network Manager here. This is production level tool set, which offers you the abilities to setup you network including the Keys and CAs
You are referring to the documentation for Corda 3.1 and now we are on Corda 4.5, we highly suggest you always follow the latest documentation as the code implementation might vary from version to version.
I am trying to port Azure IoT SDKs for C to STM32 controller. I am using wolfSSL library for TLS version 1.2 and I am able to build the code successfully in OpenSTM32 environment.
But, after establishing successful connection with Azure server, I am unable to establish TLS handshake with the server.
I am using OpenSTM32’s example user_settings.h file from wolfSSL library to build wolfSSL library.
Do I need to make any additional changes in the WolfSSL library to use it with Azure?
OR
Is there any other TLS library, which can be used with Azure IoT SDK for C and STM32 controller?
I have managed to get it working.
There were issues with the buffer sizes and server timeouts.
Increasing the buffer size and optimizing the sending logic solved the issue.
Now, I am able to access every functionality of Azure IoT SDK for C !