Hi Javier!
In the CSDK, the libisi.so.1 is a symbolic link:
libisi.so.1 -> ./libisi_o11.so.1.2
And on the server side it's a symblink too:
libisi.so.1 -> ./libisi_gsk.so.1.2
If I would copy libisi.so.1 from the server to the client, that would overwrite the original libisi_o11.so.1.2 library pointed by libisi.so.1 symblink and break the installation ...
I have done the following in my CSDK installation dir:
$ cd $INFORMIXDIR/lib
$ mv libisi.so.1 libisi.so.1.orig
$ cp <server-install-dir>/lib/libisi_gsk.so.1.2 .
$ ln -s libisi_gsk.so.1.2 libisi.so.1
So now I have:
lrwxrwxrwx 1 informix informix 17 Aug 18 16:31 libisi.so.1 -> libisi_gsk.so.1.2
lrwxrwxrwx 1 informix informix 19 Aug 13 15:45 libisi.so.1.orig -> ./libisi_o11.so.1.2
-rwxr-xr-x 1 informix informix 118656 Aug 18 16:31 libisi_gsk.so.1.2
-rwxr-xr-x 1 informix informix 201136 Aug 13 15:45 libisi_o10.so.1.2
-rwxr-xr-x 1 informix informix 203872 Aug 13 15:45 libisi_o11.so.1.2
-rwxr-xr-x 1 informix informix 204448 Aug 13 15:45 libisi_oos.so.1.2
And symbols seem to be satisfied:
informix@toro:/opt3/dbs/ifx/CSDK-4.50.FC4W1/lib$ ldd -r libisi.so.1
linux-vdso.so.1 (0x00007ffd3c35b000)
libgsk8iccs_64.so => /usr/lib/x86_64-linux-gnu/libgsk8iccs_64.so (0x00007f7a4d9d0000)
libgsk8ssl_64.so => /usr/lib/x86_64-linux-gnu/libgsk8ssl_64.so (0x00007f7a4d486000)
libgsk8km_64.so => /usr/lib/x86_64-linux-gnu/libgsk8km_64.so (0x00007f7a4d27a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7a4d0b9000)
/lib64/ld-linux-x86-64.so.2 (0x00007f7a4dd82000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f7a4d098000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f7a4d091000)
libgsk8cms_64.so => /usr/lib/x86_64-linux-gnu/libgsk8cms_64.so (0x00007f7a4cb60000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f7a4c9dc000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f7a4c859000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f7a4c83f000)
Then I have re-created the keystore with the GSKit utility on client side:
$ cd $INFORMIXDIR
$ mkdir my_ssl_2
$ cd my_ssl_2
$ gsk8capicmd_64 -keydb -create -db ifx_client_keystore.p12 -pw "Fourjs/123" -type pkcs12 -stash
$ gsk8capicmd_64 -cert -add -db ifx_client_keystore.p12 -pw "Fourjs/123" -label ifx_encrypt -file ssl_idstoro3.cert.pem -format ascii
Then changed the config file to point to the new files:
$ cat etc/conssl.cfg
SSL_KEYSTORE_FILE /opt3/dbs/ifx/CSDK-4.50.FC4W1/my_ssl_2/ifx_client_keystore.p12
SSL_KEYSTORE_STH /opt3/dbs/ifx/CSDK-4.50.FC4W1/my_ssl_2/ifx_client_keystore.stl
And now it connects!
LD_DEBUG=all output shows that the GSKit lib is used:
24182: file=/opt3/dbs/ifx/CSDK-4.50.FC4W1/lib/libisi.so.1 [0]; dynamically loaded by dbaccess [0]
24182: file=/opt3/dbs/ifx/CSDK-4.50.FC4W1/lib/libisi.so.1 [0]; generating link map
24182: dynamic: 0x00007fcd2d9c3da8 base: 0x00007fcd2d7ad000 size: 0x0000000000217b70
24182: entry: 0x00007fcd2d7b3130 phdr: 0x00007fcd2d7ad040 phnum: 8
24182:
24182:
24182: file=libgsk8iccs_64.so [0]; needed by /opt3/dbs/ifx/CSDK-4.50.FC4W1/lib/libisi.so.1 [0]
24182: find library=libgsk8iccs_64.so [0]; searching
24182: search path=/opt3/dbs/ifx/CSDK-4.50.FC4W1/lib:/opt3/dbs/ifx/CSDK-4.50.FC4W1/lib/esql:/opt3/dbs/ifx/IDS-14.10.FC1/lib:/opt3/dbs/ifx/IDS-14.10.FC1/lib/esql:tls/haswell/x86_64:tls/haswell:tls/x86_64:tls:haswell/x86_64:haswell:x86_64: (LD_LIBRARY_PATH)
24182: trying file=/opt3/dbs/ifx/CSDK-4.50.FC4W1/lib/libgsk8iccs_64.so
24182: trying file=/opt3/dbs/ifx/CSDK-4.50.FC4W1/lib/esql/libgsk8iccs_64.so
24182: trying file=/opt3/dbs/ifx/IDS-14.10.FC1/lib/libgsk8iccs_64.so
24182: trying file=/opt3/dbs/ifx/IDS-14.10.FC1/lib/esql/libgsk8iccs_64.so
24182: trying file=tls/haswell/x86_64/libgsk8iccs_64.so
24182: trying file=tls/haswell/libgsk8iccs_64.so
24182: trying file=tls/x86_64/libgsk8iccs_64.so
24182: trying file=tls/libgsk8iccs_64.so
24182: trying file=haswell/x86_64/libgsk8iccs_64.so
24182: trying file=haswell/libgsk8iccs_64.so
24182: trying file=x86_64/libgsk8iccs_64.so
24182: trying file=libgsk8iccs_64.so
24182: search cache=/etc/ld.so.cache
24182: trying file=/usr/lib/x86_64-linux-gnu/libgsk8iccs_64.so
24182:
24182: file=libgsk8iccs_64.so [0]; generating link map
24182: dynamic: 0x00007fcd2d7a0988 base: 0x00007fcd2d636000 size: 0x0000000000176b48
24182: entry: 0x00007fcd2d642ca0 phdr: 0x00007fcd2d636040 phnum:
When I switch back to OpenSSL libs, even with the keystore produced by GSKit tool, it fails....
To get details of the error message, I got to the server env and type:
informix@toro:/opt3/dbs/ifx/IDS-14.10.FC4W1$ finderr -28014
-28014 Secure Sockets Layer error.
An error occurred during a Secure Socket Layer operation. For more information,
refer to the accompanying IBM Global Security Kit (GSKit) error message.
Seb
------------------------------
Sebastien FLAESCH
------------------------------
Original Message:
Sent: Tue August 18, 2020 10:22 AM
From: Javier Sagrera
Subject: Major Issues with Windows CSDK4.50.FC4W1
If you are getting that "cannot open net.iem" error you must have CSDK in a separate INFORMIXDIR than the server, so CSDK would be using OpenSSL and not GSKit. That's fine, but it means you will need to do the stuff to import the certificate from the server using OpenSSL (which you may already tried).
If you want go that route, I suggest to copy the 'net.iem' from the server 'msg/en_us/0333' directory into the CSDK dir, at least you would be able to see a proper error message (sometimes it helps).
You can also just pick the 'libisi.so.1' from the server and use that in the CSDK lib directory. That way CSDK would use GSKit so you can use the same files as the server. It's a good way to validate that TLS is working on the server side before moving into configuring the client with OpenSSL.
------------------------------
Javier Sagrera
Original Message:
Sent: Tue August 18, 2020 10:01 AM
From: Sebastien FLAESCH
Subject: Major Issues with Windows CSDK4.50.FC4W1
So.... I have now IDS 14.10.FC4W1 installed, and still it cannot connect through TLS.
Grrrrr...
Please check this and let me know what's wrong... server name is now idstoro3 ...
informix@toro:/opt3/dbs/ifx/IDS-14.10.FC4W1/ssl$ echo $INFORMIXDIR
/opt3/dbs/ifx/IDS-14.10.FC4W1
$ gsk8capicmd_64 -version:
GSKCAPICMD
==========
@(#)CompanyName: IBM Corporation
@(#)LegalTrademarks: IBM
@(#)FileDescription: IBM Global Security Toolkit
@(#)FileVersion: 8.0.55.12
@(#)InternalName: gskcapicmd
@(#)LegalCopyright: Licensed Materials - Property of IBM GSKit
(C) Copyright IBM Corp.1995, 2019
All Rights Reserved. US Government Users
Restricted Rights - Use, duplication or disclosure
restricted by GSA ADP Schedule Contract with IBM Corp.
@(#)OriginalFilename: gsk8capicmd_64
@(#)ProductName: gsk8l (GoldCoast Build develop) 191211
@(#)ProductVersion: 8.0.55.12
In /etc/services:
idstoro3 9288/tcp
ssl_idstoro3 9289/tcp <---
lo_idstoro3 15972/tcp
idstoro3_json 19159/tcp #JSON listener for idstoro3
In $INFORMIXDIR/etc/sqlhosts.idstoro3:
idstoro3 onsoctcp toro idstoro3
lo_idstoro3 onsoctcp 127.0.0.1 lo_idstoro3
ssl_idstoro3 onsocssl toro ssl_idstoro3
In $INFORMIXDIR/etc/onconfig.idstoro3:
DBSERVERNAME idstoro3
DBSERVERALIASES lo_idstoro3,ssl_idstoro3
SSL_KEYSTORE_LABEL ifx_encrypt
NETTYPE socssl,1,50,NET
VPCLASS encrypt,num=1
In $INFORMIXDIR/ssl:
gsk8capicmd_64 -keydb -create -db idstoro3.kdb -pw fourjs -type pkcs12 -stash
gsk8capicmd_64 -cert -create -db idstoro3.kdb -stashed -label ifx_encrypt \
-size 2048 -default_cert yes -expire 32000 -dn "CN=ssl_idstoro3" \
-ca true -sigalg SHA256WithRSA
gsk8capicmd_64 -cert -extract -db idstoro3.kdb -stashed -label ifx_encrypt \
-target ssl_idstoro3.cert.pem
Checking server certificate with openssl x509 command:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 7652763328046081192 (0x6a3413b36652a4a8)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN = ssl_idstoro3
Validity
Not Before: Aug 17 13:58:00 2020 GMT
Not After : Mar 30 13:58:00 2108 GMT
Subject: CN = ssl_idstoro3
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
...
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Key Identifier:
BA:2D:F3:7C:E9:9E:AD:23:46:35:17:E9:61:70:87:76:55:AD:15:DC
X509v3 Authority Key Identifier:
keyid:BA:2D:F3:7C:E9:9E:AD:23:46:35:17:E9:61:70:87:76:55:AD:15:DC
Signature Algorithm: sha256WithRSAEncryption
53:af:06:f4:c2:1b:fa:48:58:d8:9d:df:e1:99:e8:85:10:4d:
...
In $INFORMIXDIR/idstoro3.log file I can see:
15:42:09 using ISI 1.2 with GSKit 8.0.55.12, ICC 8.6.0.0
15:42:09 Secure Sockets Layer (SSL) initialized.
...
15:46:04 listener-thread@asfslsqi.c:1473: err = -27001: oserr = 0: errstr = from localhost to server ssl_idstoro3 : Read error occurred during connection attempt.
Client side with CSDK 4.50.FC4W1:
informix@toro:/opt3/dbs/ifx/CSDK-4.50.FC4W1/my_ssl$ echo $INFORMIXSERVER
ssl_idstoro3
informix@toro:/opt3/dbs/ifx/CSDK-4.50.FC4W1/my_ssl$ cat ../etc/conssl.cfg
SSL_KEYSTORE_FILE /opt3/dbs/ifx/CSDK-4.50.FC4W1/my_ssl/ifx_client_keystore.p12
SSL_KEYSTORE_STH /opt3/dbs/ifx/CSDK-4.50.FC4W1/my_ssl/ifx_client_keystore.stl
informix@toro:/opt3/dbs/ifx/CSDK-4.50.FC4W1/my_ssl$ dbaccess test1 -
28014: Cannot open file 'net.iem'.
This corresponds to the server log msg:
16:01:10 listener-thread@asfslsqi.c:1473: err = -27001: oserr = 0: errstr = from localhost to server ssl_idstoro3 : Read error occurred during connection attempt.
Any idea what's wrong?
Seb
------------------------------
Sebastien FLAESCH
Original Message:
Sent: Mon August 17, 2020 02:02 PM
From: Martin Fuerderer
Subject: Major Issues with Windows CSDK4.50.FC4W1
Hi Sebastien,
hmm. Interesting.
Using GSKit 8.0.55.12, I ran your commands (with my additional change), i.e. as follows:
gsk8capicmd_64 -keydb -create -db idstoro2.kdb -pw fourjs -type pkcs12 -stash
gsk8capicmd_64 -cert -create -db idstoro2.kdb -stashed -label ifx_encrypt \
-size 2048 -default_cert yes -expire 32000 -dn "CN=ssl_idstoro2" -ca true -sigalg SHA256WithRSA
gsk8capicmd_64 -cert -extract -db idstoro2.kdb -stashed -label ifx_encrypt -target ssl_idstoro2.cert.pem
then I look at the resulting PEM file with the following command:
openssl x509 -in ssl_idstoro2.cert.pem -text -noout
and in the output, I see the following X509 v3 extensions:
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Key Identifier:
36:94:03:23:60:3F:16:D8:38:19:68:90:31:0C:6D:2B:29:AB:3E:63
X509v3 Authority Key Identifier:
keyid:36:94:03:23:60:3F:16:D8:38:19:68:90:31:0C:6D:2B:29:AB:3E:63
Whereas, using that same command to look at the PEM file with your certificate,
I only see:
X509v3 extensions:
X509v3 Subject Key Identifier:
30:A7:CB:96:01:83:01:EA:4E:6C:51:CF:62:4D:DF:91:BC:6E:5D:04
X509v3 Authority Key Identifier:
keyid:30:A7:CB:96:01:83:01:EA:4E:6C:51:CF:62:4D:DF:91:BC:6E:5D:04
It seems to me, that the older GSKit version 8.0.50.x that you are using (i.e. that came with 14.10.xC1),
does not add the "Basic constraint CA:True" X509 v3 extension to the certificate, even though you
specified the "-ca true" command line option for the respective gsk8capicmd_64 command.
Hmm. A missing "Basic constraint CA:True" X509 v3 extension is known to cause problems with
OpenSSL 1.1 versions, we have seen this before. We did not see this problem with OpenSSL 1.0 versions.
Are you using OpenSSL 1.1?
Regards, Martin
--
Martin Fuerderer Informix Development Germany
| HCL Technologies Germany GmbH Frankfurter Ring 17 80807 Munich, Germany http://www.hcltech.com/de |
--DISCLAIMER-- ------------------------------------------------------------------------------------------------------------ This document is intended for transmission to the named recipient only. If you are not that person, you should note that legal rights reside in this document and you are not authorized to access, read, disclose, copy, use or otherwise deal with it and any such actions are prohibited and may be unlawful. The views expressed in this document are not necessarily those of HCL Technologies Ltd. Notice is hereby given that no representation, contract or other binding obligation shall be created by this e-mail, which must be interpreted accordingly. Any representations, contractual rights or obligations shall be separately communicated in writing and signed in the original by a duly authorized officer of the relevant company. ------------------------------------------------------------------------------------------------------------
::DISCLAIMER::
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
Original Message:
Sent: 8/17/2020 12:15:00 PM
From: Sebastien FLAESCH
Subject: RE: Major Issues with Windows CSDK4.50.FC4W1
Sorry "-ca true -sigalg SHA256WithRSA" options did not help...
------------------------------
Sebastien FLAESCH
Original Message:
Sent: Mon August 17, 2020 11:57 AM
From: Martin Fuerderer
Subject: Major Issues with Windows CSDK4.50.FC4W1
Hi Sebastien,
when creating your server certificate, can you please try with using the following parameters: "-ca true -sigalg SHA256WithRSA"?
I.e., please replace your command
gsk8capicmd_64 -cert -create -db idstoro2.kdb -stashed -label ifx_encrypt \
-size 2048 -default_cert yes -expire 32000 -dn "CN=ssl_idstoro2" \
-sig_alg SHA512
with this command:
gsk8capicmd_64 -cert -create -db idstoro2.kdb -stashed -label ifx_encrypt \ -size 2048 -default_cert yes -expire 32000 -dn "CN=ssl_idstoro2" \
-ca true -sigalg SHA256WithRSA
Regards, Martin
--
Martin Fuerderer Informix Development Germany
| HCL Technologies Germany GmbH Frankfurter Ring 17 80807 Munich, Germany http://www.hcltech.com/de |
--DISCLAIMER-- ------------------------------------------------------------------------------------------------------------ This document is intended for transmission to the named recipient only. If you are not that person, you should note that legal rights reside in this document and you are not authorized to access, read, disclose, copy, use or otherwise deal with it and any such actions are prohibited and may be unlawful. The views expressed in this document are not necessarily those of HCL Technologies Ltd. Notice is hereby given that no representation, contract or other binding obligation shall be created by this e-mail, which must be interpreted accordingly. Any representations, contractual rights or obligations shall be separately communicated in writing and signed in the original by a duly authorized officer of the relevant company. ------------------------------------------------------------------------------------------------------------
::DISCLAIMER::
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
Original Message:
Sent: 8/17/2020 11:30:00 AM
From: Sebastien FLAESCH
Subject: RE: Major Issues with Windows CSDK4.50.FC4W1
My main goal is to test the CSDK 4.50.FC4W1 by using the OpenSSL libraries available on the system (or those we ship with our product)
My CSDK and IDS server are installed on the same Linux Debian 10 machine, but in different directories so I assume its' not considered as a "co-located" install... right?
I assume also that I can configure my IDS 14.10.FC1 server with GSKit, to create a PKCS12-type keystore, and communicate with the CSDK client using OpenSSL... right?
We are downloading IDS 14.10.FC4W1 but it would be nice make it work with my existing config.
Here is what I did so far:
IDS 14.10.FC1 server:
onconfig entries:
====================================
DBSERVERNAME idstoro2
DBSERVERALIASES lo_idstoro2,ssl_idstoro2
SSL_KEYSTORE_LABEL ifx_encrypt
NETTYPE socssl,1,50,NET
VPCLASS encrypt,num=1
Commands to create the keystore:
====================================
$ cd $INFORMIXDIR
$ mkdir ssl
$ cd ssl
$ gsk8capicmd_64 -keydb -create -db idstoro2.kdb -pw fourjs -type pkcs12 -stash
$ gsk8capicmd_64 -cert -create -db idstoro2.kdb -stashed -label ifx_encrypt \
-size 2048 -default_cert yes -expire 32000 -dn "CN=ssl_idstoro2" \
-sig_alg SHA512
$ gsk8capicmd_64 -cert -extract -db idstoro2.kdb -stashed -label ifx_encrypt \
-target ssl_idstoro2.cert.pem
On the CSDK client side:
====================================================
$ cat $INFORMIXDIR/etc/conssl.cfg
SSL_KEYSTORE_FILE /opt3/dbs/ifx/CSDK-4.50.FC4W1/my_ssl/ifx_client_keystore.p12
SSL_KEYSTORE_STH /opt3/dbs/ifx/CSDK-4.50.FC4W1/my_ssl/ifx_client_keystore.stl
$ cd $INFORMIXDIR
$ mkdir my_ssl
$ cp /opt3/dbs/ifx/IDS-14.10.FC1/ssl/ssl_idstoro2.cert.pem .
$ openssl pkcs12 -export -nokey -in ssl_idstoro2.cert.pem -out ifx_client_keystore.p12
=> enter mypswd twice...
$ onkstash ifx_client_keystore.p12 mypswd
$ export INFORMIXSERVER=ssl_idstoro2
$ cat $INFORMIXSQLHOSTS
#-- IDS 14
idstoro2 onsoctcp toro idstoro2
lo_idstoro2 onsoctcp 127.0.0.1 lo_idstoro2
ssl_idstoro2 onsocssl toro ssl_idstoro2
$ cat /etc/services
...
idstoro2 9188/tcp
ssl_idstoro2 9189/tcp
lo_idstoro2 19515/tcp
idstoro2_json 12624/tcp
And now I get this error in server log file:
17:28:43 listener-thread@asfslsqi.c:1473: err = -27001: oserr = 0: errstr = from localhost to server ssl_idstoro2 : Read error occurred during connection attempt.
I tried this from client side:
$ openssl s_client -connect toro:9189
CONNECTED(00000003)
Can't use SSL_get_servername
depth=0 CN = ssl_idstoro2
verify error:num=18:self signed certificate
verify return:1
depth=0 CN = ssl_idstoro2
verify return:1
---
Certificate chain
0 s:CN = ssl_idstoro2
i:CN = ssl_idstoro2
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIC9DCCAdygAwIBAgIID3VyojHG3f8wDQYJKoZIhvcNAQELBQAwFzEVMBMGA1UE
AwwMc3NsX2lkc3Rvcm8yMCAXDTIwMDgxNjE1MDg1NFoYDzIxMDgwMzI5MTUwODU0
WjAXMRUwEwYDVQQDDAxzc2xfaWRzdG9ybzIwggEiMA0GCSqGSIb3DQEBAQUAA4IB
DwAwggEKAoIBAQCmhgQMZmMfCiqvXhPEJVJozxka/bNwbf9bRfk40vi12n+jPOZw
41/OsVx9QT9+RC8Sq3qfcgIMKsLgqZf2Klf1qjfDSkR1Couje0y6ShdoUA28jwFJ
ctbKp9VwEhZKIA9UCuK8MwCvX2QkQVKJC+4AzLsNzOIMJVPDyqCIx0SBJBrV2rj2
kSSeZOpkXoYlCv3+fTGS79KGlMK3ACG2C6Gsza47O4vADp8bUGH4IgY9OpBTldcN
ODgRW3Z4TP6YZBgMZaYjseXZqLicib47bCYApXOkRYM02dNgeSRWasBBBqI9ACZL
QtgB1SQUkvyrjuBm7hmGTZ8MzX27JKMtrmirAgMBAAGjQjBAMB0GA1UdDgQWBBQw
p8uWAYMB6k5sUc9iTd+RvG5dBDAfBgNVHSMEGDAWgBQwp8uWAYMB6k5sUc9iTd+R
vG5dBDANBgkqhkiG9w0BAQsFAAOCAQEAV7LgRS6E/xTSudCRPZRrK8sn7kfwmHcF
v1twJMsPvQOkJmj3UePxxtwmC2XnxtmWFaoVXw1+uNxm01ObZu3uW0INJ2F8VX5T
O0TJ3JDZ2QYF/gNanX1Vu+pvXGj5dJR9dfGBaLQAyjkrJ/g9gANO6CTs+7+2HLVS
vex1zAccRmW4+PDQ5LdEGcLsjIqeMBdTrZdXpPU47eI4zg0guGvijfVIS+5NrCtX
TYqMdQ/kMu7ttXwjvmOg5/79RbXvzBfBAGZRzRuUi9hdZBqpEWdp1/ZVVdpTCfu9
+Lfw1f3lRJt9QXo9Ph35y/7JGZERcsCkOsHpYGQ+6+8kyF+LgHCg5g==
-----END CERTIFICATE-----
subject=CN = ssl_idstoro2
issuer=CN = ssl_idstoro2
---
No client certificate CA names sent
---
SSL handshake has read 921 bytes and written 601 bytes
Verification error: self signed certificate
---
New, TLSv1.2, Cipher is AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : AES128-GCM-SHA256
Session-ID: CAB97E02817E14395E812001763A8D9631DF77A85EE985FB564316965ABD483F
Session-ID-ctx:
Master-Key: 38178EB2C6EF4434A27DDABC33B758C853DDC8394B68710255D02DD679F5FA42B2298DEE527FFFFB6050EFC97F03199E
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1597678152
Timeout : 7200 (sec)
Verify return code: 18 (self signed certificate)
Extended master secret: yes
---
This is all in a dev/test env, no hurry.
Seb
------------------------------
Sebastien FLAESCH
Original Message:
Sent: Mon August 17, 2020 10:13 AM
From: Martin Fuerderer
Subject: Major Issues with Windows CSDK4.50.FC4W1
Hi Sebastien,
yes, the command you cited:
openssl -pkcs12 -export -out client.p12 -passout pass:CLIENTPASSWD \
-in SSL_KEYSTORE_LABEL -file SSL_KEYSTORE_LABEL.cert.pem [ -caname LABEL ]
is incorrect in the documentation.
The correct command is:
openssl pkcs12 -export -out client.p12 -passout pass:CLIENTPASSWD \
-in SSL_KEYSTORE_LABEL.cert.pem [ -caname LABEL ]
I'm working with my documentation contact to get this issue fixed.
[ The command option really is "-export", even though it does not sound very intuitive. See also
(We are also working on a more comprehensive documentation update regarding this topic.)
How did you create the server PKCS#12 keystore that seemingly does not work with the GSKit of 14.10.xC1?
(I admit, that I've not worked a lot with GSKit version 8.0.50.x, but rather with newer versions 8.0.55.x.)
I'm quite sure, that e.g. GSKit versions 8.0.55.9 or 8.0.55.12 can properly read a PKCS#12 keystore,
whether it was created with the appropriate GSKit command or the corresponding OpenSSL command.
When using the GSKit utility, it may be better to include the file type as explicit command line parameter
(rather than relying on the interpretation of the file name extension). Especially when creating a keystore,
use "-type p12" in addition to giving the file name an extension of ".p12". Following a sequence of GSKit
command to create a DB client keystore:
Create an empty PKCS#12 keystore for the client and (optionally) stash the password:
gsk8capicmd_64 -keydb -create -db client.p12 -pw CLIENTPASSWD \
[ -stash ] -type p12 -f
Add the server's certificate in the PEM file to the keystore (using the stashed password):
gsk8capicmd_64 -cert -add -db client.p12 -stashed \
-file SSL_KEYSTORE_LABEL.cert.pem -label <label> -format ascii
If you have additional CA certificates in additional PEM files,
repeat the above command for each additional CA certificate,
or use the import action with a command like the following:
gsk8capicmd_64 -cert -import -file <PEM file> -type ascii \
-target client.p12 -target_stashed -target_type p12 [ -new_label <label> ]
You can see the use of the "-type p12" and "-target_type p12" command line parameters.
You can check whether GSKit is able to read the keystore by issuing a command like
(referring to the above example):
gsk8capicmd_64 -cert -list -db client.p12 -pw CLIENTPASSWD
This should list the labels (and type) of the entries in the keystore.
If your server's certificate is not a self-signed certificate (but signed by some CA), then I seem
to remember the GSKit speciality that the server's keystore not only needs to contain the
server's certificate (often called "user certificate") and the corresponding private key, but also
the complete chain of CA certifciates (including the root CA certificate). If the CA certificates
are not in the server's keystore, then I seem to remember that GSKit refuses to send the server's
certificate to the client. Though, judging from the error message that you see, I assume, that this
is not (yet) your problem. (OpenSSL does not require the CA certificate(s) to be present in the
server's keystore. For OpenSSL it is sufficient that the client keystore contains these, as the client
needs them to authenticate the server.)
Regards, Martin
--
Martin Fuerderer Informix Development Germany
| HCL Technologies Germany GmbH Frankfurter Ring 17 80807 Munich, Germany http://www.hcltech.com/de |
--DISCLAIMER-- ------------------------------------------------------------------------------------------------------------ This document is intended for transmission to the named recipient only. If you are not that person, you should note that legal rights reside in this document and you are not authorized to access, read, disclose, copy, use or otherwise deal with it and any such actions are prohibited and may be unlawful. The views expressed in this document are not necessarily those of HCL Technologies Ltd. Notice is hereby given that no representation, contract or other binding obligation shall be created by this e-mail, which must be interpreted accordingly. Any representations, contractual rights or obligations shall be separately communicated in writing and signed in the original by a duly authorized officer of the relevant company. ------------------------------------------------------------------------------------------------------------
::DISCLAIMER::
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
Original Message:
Sent: 8/17/2020 9:02:00 AM
From: Sebastien FLAESCH
Subject: RE: Major Issues with Windows CSDK4.50.FC4W1
Hi Martin,
I am trying to setup TLS/SSL config with Informix CSDK 4.50.FC4W1 and IDS 14.10.FC1.
Both client and server are on the same Linux Debian 10 box.
So far, I teach myself, reading manuals and doing some tests.
I think something is wrong in this page:
https://informix.hcldoc.com/14.10/help/topic/com.ibm.sec.doc/ids_ssl_003.htm
Create the client keystore using the exported certificates in the PEM file as input:
openssl -pkcs12 -export -out client.p12 -passout pass:CLIENTPASSWD \ -in SSL_KEYSTORE_LABEL -file SSL_KEYSTORE_LABEL.cert.pem [ -caname LABEL ]
I guess "-pkcs12" should be "pkcs12", to create the client keystore...
Seems that you know what you are doing, so you may review all these doc pages ;-)
If there is a more up to date doc, please provide a link...
In fact I am using the gsk8capicmd_64 utility and GSKit on the server side...
I understand that pkcs12 type must be used for the keystore to be compatible with OpenSSL, but I am not sure what file extension I should use...
With GSKit it's .kdb but when using .p12 the server fails to start:
14:32:40 IBM Global Security Kit (GSKit) version 8.0.50.89.
14:32:40 Secure Sockets Layer error: GSK_KEYRING_OPEN_ERROR.
Seb
------------------------------
Sebastien FLAESCH
Original Message:
Sent: Mon August 03, 2020 01:36 PM
From: Martin Fuerderer
Subject: Major Issues with Windows CSDK4.50.FC4W1
With 4.50.xC4W1 and onwards, GSKit is no longer included with the IBM Informix Client SDK product package.
IBM Informix Client SDK now should use OpenSSL instead of GSKit. Since OpenSSL (contrary to GSKit) is publicly available, the user (you) are expected to have it installed already. The biggest advantage of this is that you have more control over which version of OpenSSL is used, where it is installed and how it is configured. Also, you are normally able to update your OpenSSL release version as new (security) fixes become available, without the need to wait for a new Informix Client SDK release and upgrade it.
OpenSSL uses and requires a keystore that conforms to the PKCS#12 standard. It does not know anything about the GSKit proprietary "CMS" format of the so-called "*.kdb" keystore files, and therefore cannot use them in any way. Nor can anyone (besides GSKit itself) know and use a stashed password in a GSKit-specific "*.sth" file, because the encryption and format of it is secret (fortunately).
With that, it is necessary to either manually convert an existing "*.kdb" keystore to the PKCS#12 format (i.e. a "*.p12" file), or to re-create the keystore "from scratch" (e.g. using original PEM files). And as there is no way to retrieve the password from a GSKit password stash file, it is necessary to create a new password stash file, named "*.stl", using the new utility "onkstash" that is supplied with 4.50.xC4W1. For the latter it is necessary to either know the password, or change the password using GSKit tools like "gsk8capicmd" to a known value.
Here's some information that may be helpful:
--------------------------
If you have existing keystores for your database clients SSL connections
to the database server, you may need to migrate such client keystores.
Please see sub-chapter "Configuring a client for SSL connections" in
the "Security" manual for more information.
When keystore migration is necessary and what steps to perform:
- If your database client installation is co-located with the database
server installation, the database client continues to use GSKit as
encryption library. In this case, keystore migration is not necessary.
- If your database client installation is stand-alone, it will use
OpenSSL as encryption library.
- If your client keystore has the GSKit-proprietary format "CMS"
(usually with file extension "*.kdb"), then this keystore needs
to be converted to a PKCS#12 keystore:
As the CMS format is GSKit-specific, you need the GSKit command
"gsk8capicmd" (or "gsk7capicmd") in order to convert the keystore.
Use a command like:
gsk8capicmd -keydb -convert -db KEYSTOREFILE.kdb -pw PASSWORD
-old_format cms -new_db KEYSTOREFILE.p12 -new_pw PASSWORD
-new_format pkcs12
- Create a stash file with the keystore password for use with OpenSSL.
Use the utility onkstash to stash the keystore password:
onkstash KEYSTOREFILE.p12 PASSWORD
(This step is also needed in case your keystore already had the
PKCS#12 format.)
--------------------------In fact, I thought that this was included in the documentation for 14.10.xC4W1,
but admit that currently I cannot locate it. I will find it or see to it that it gets included.
Regards, Martin
--
Martin Fuerderer Informix Development Germany
| HCL Technologies Germany GmbH Frankfurter Ring 17 80807 Munich, Germany http://www.hcltech.com/de |
--DISCLAIMER-- ------------------------------------------------------------------------------------------------------------ This document is intended for transmission to the named recipient only. If you are not that person, you should note that legal rights reside in this document and you are not authorized to access, read, disclose, copy, use or otherwise deal with it and any such actions are prohibited and may be unlawful. The views expressed in this document are not necessarily those of HCL Technologies Ltd. Notice is hereby given that no representation, contract or other binding obligation shall be created by this e-mail, which must be interpreted accordingly. Any representations, contractual rights or obligations shall be separately communicated in writing and signed in the original by a duly authorized officer of the relevant company. ------------------------------------------------------------------------------------------------------------
::DISCLAIMER::
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
Original Message:
Sent: 7/29/2020 1:31:00 PM
From: TOM GIRSCH
Subject: Major Issues with Windows CSDK4.50.FC4W1
All, a warning.
I installed the latest release of CSDK for Windows, 4.50.FC4W1, and it's got a few problems.
- The default install path changed, and not everything seems to have picked up on that change. So when you fire up, e.g., ConnectTest or any other ODBC configuration deal, it complains that INFORMIXDIR is not set or doesn't include libisi.dll.1; this problem can be manually worked around by running the program from a command prompt where you've manually set INFORMIXDIR correctly. Not ideal. And for whatever reason, changes in SetNet32 seem not to be honored on the systems I've tested.
- Once you've worked around the above, if you have any SSL connections, it will complain about not being able to find client.p12 and client.stl. Note that these file extensions are not the usual client.kdb/client.sth files we're used to. Using conssl.cfg to point to the correct files won't work either. I'm working with support here, and they've asked me to try manually running onkstash to generate a new password stash file. But obviously, I shouldn't have to do ANY of this.
As of this writing, I have been unable to get FC4W1 to work. Ultimately, I reverted to FC3, where everything works fine.
The good news here is that this is apparently part of an effort by IBM to phase out the kludgy GSKit and switch to using OpenSSL like the rest of modern civilization. However, they shouldn't have broken stuff that already worked in the process, and some heads up would have been nice. Even the tech support agent hadn't heard about any of these changes until he went digging.
As of right now, it looks to me as if FC4W1 has been pulled from Passport Advantage, although that could just be IBM's usual MO of making things extremely difficult to find on Passport Advantage. ;)
Two final notes:
1. A 14.10.FC4W1 engine seems to recognize client.kdb/client.sth without issue, so whatever the problem is here, it seems to be unique to the SDK (and possibly even the Windows SDK)
2. I've done a bunch of testing with JDBC 4.50.FC4W1 and that seems to work just fine in my limited testing.
------------------------------
TOM GIRSCH
------------------------------
#Informix