Informix

Expand all | Collapse all

Major Issues with Windows CSDK4.50.FC4W1

Martin FuerdererMon August 17, 2020 10:31 AM

  • 1.  Major Issues with Windows CSDK4.50.FC4W1

    Posted Wed July 29, 2020 01:31 PM
    Edited by TOM GIRSCH Thu July 30, 2020 11:23 AM

    All, a warning.

    I installed the latest release of CSDK for Windows, 4.50.FC4W1, and it's got a few problems.

    1. 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.
    2. 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
    ------------------------------


  • 2.  RE: Major Issues with Windows CSDK4.50.FC4W1

    Posted Thu July 30, 2020 03:54 AM
      |   view attached
    Hi Tom,

    You seem to have encountered 3 problems as per email.
    1. Install issue of not installing in default location?
    2. Setnet32 being not effective
    3. OpenSSL seems to have issue with CSDK 4.50.FC4W1 on Windows.

    I installed CSDK 4.50.FC4W1 (in my chosen location) and can see Setnet32 settings being effective on Registry (attaching the screen shots). You are already in touch with Tech Support, I will get more information accordingly. However if you have anything additional to share on the forum to reproduce the issues you are facing, please do so.

    Thanks & Regards
    -Shesh

    ------------------------------
    Sheshnarayan Agrawal
    ------------------------------

    Attachment(s)

    pdf
    CSDK450FC4W1.pdf   251 KB 1 version


  • 3.  RE: Major Issues with Windows CSDK4.50.FC4W1

    Posted Thu July 30, 2020 11:12 AM
    On your first point, it's more that the default location has changed that that it's not correct. I was speculating that this might factor into why INFORMIXDIR doesn't appear to be honored. In earlier versions, the install path is "C:\Program Files\Informix Client-SDK\"; with FC4W1, it's "C:\Program Files\IBM Informix Client-SDK\"

    On the second point, I'm not super clear on just what's going on. ConnectTest (for example) on FC4W1 complains that it can't find libisi.dll.1 because INFORMIXDIR is not properly set. Same program on FC3, I don't get that error. In both cases, if I open a command prompt and use "set" to look at the environment, INFORMIXDIR is not set. But for FC4W1, if I manually set it from a command prompt and then run ConnectTest from there, I no longer get the libisi error. It looks, however, like INFORMIXDIR is being set in the registry rather than in the environment, so I need to do some more FC4W1 testing to see what's going on.

    On the third point, you're correct. FC4W1 does not honor %INFORMIXDIR%\etc\client.kdb and client.sth. I even created a new keystore with FC4W1's version of the gskit, and it still didn't honor it, with or without conssl.cfg pointing to it. All of this worked fine on FC3.

    The support rep has replicated all of these issues. The support ticket number is TS003986256 for reference.


    ------------------------------
    TOM GIRSCH
    ------------------------------



  • 4.  RE: Major Issues with Windows CSDK4.50.FC4W1

    Posted Fri July 31, 2020 05:15 AM
    Hi Tom,
    As you know from CSDK 4.50.xC4 onward OpenSSL support is introduced. This support currently requires INFORMIXDIR to be set on "System Environment", it doesn't honor INFORMIXDIR setting in the registry using SETNET32. It should work without needing to set INFORMIXDIR in the "System Environment". Defect idsdb00106353 has been opened to address the above issue. Kindly follow up with your Tech Support contact on the latest status. Once the issue is addressed, the behavior should be same as FC3. Until you get the fix, you can workaround the problem by setting INFORMIXDIR in the System Environment.

    Thanks
    -Shesh


    ------------------------------
    Sheshnarayan Agrawal
    ------------------------------



  • 5.  RE: Major Issues with Windows CSDK4.50.FC4W1

    Posted Mon August 03, 2020 09:33 AM

    Shesh:

    That resolves the dll problem, which I was already able to work around on my own; it does NOT resolve the SSL keystore/stash problem, which is the much larger issue.



    ------------------------------
    TOM GIRSCH
    ------------------------------



  • 6.  RE: Major Issues with Windows CSDK4.50.FC4W1

    Posted Mon August 03, 2020 09:58 AM
    Tom,
    We have found some steps in the documentation is missing with respect to setting up client side OpenSSL. Which is also being fixed in the documentation. Tech support engineer should be able to help you on the same as well, as part of the case you have already opened.

    Thanks
    -Shesh

    ------------------------------
    Sheshnarayan Agrawal
    ------------------------------



  • 7.  RE: Major Issues with Windows CSDK4.50.FC4W1

    Posted Mon August 03, 2020 10:03 AM

    Shesh:

    But the old GSKit way should still work, and does not. IBM/HCL don't really want to force clients to do a massive redeploy of SSL as part of a minor CSDK revision, do they?

    I fully support a transition to OpenSSL support, but that transition should break existing configurations.



    ------------------------------
    TOM GIRSCH
    ------------------------------



  • 8.  RE: Major Issues with Windows CSDK4.50.FC4W1

    Posted Mon August 03, 2020 01:37 PM
    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.






  • 9.  RE: Major Issues with Windows CSDK4.50.FC4W1

    Posted Mon August 03, 2020 01:51 PM
    Getting rid of GSKit and going to an entitlement-free version of the SDK is a laudable goal, to be sure. But did nobody at IBM/HCL think that abruptly yanking GSKit support wouldn't be a problem?

    Because of the INFORMIXDIR issue I've also found here, we've decided for the moment to revert to FC3. When a future release of FC4 (or later) has the INFORMIXDIR issue fixed, I'll try again with the OpenSSL keystore.

    ------------------------------
    TOM GIRSCH
    ------------------------------



  • 10.  RE: Major Issues with Windows CSDK4.50.FC4W1

    Posted Mon August 17, 2020 09:02 AM
    Edited by Sebastien FLAESCH Mon August 17, 2020 09:22 AM
    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
    ------------------------------



  • 11.  RE: Major Issues with Windows CSDK4.50.FC4W1

    Posted Mon August 17, 2020 10:09 AM

    That extra "-" is one of the issues we found to be wrong in the  documentation (which is currently 'under' review).

    With 14.10.FC4W1 and 4.50.FC4W1 you should use '.p12'.  It is the extension server and client expect for the keystore as it has a pkcs12 inside.  By default server will look for a '$INFORMIXDIR/ssl/$INFORMIXSERVER.p12' file and the client for '$INFORMIXDIR/etc/client.p12'.  

    The stash file depends on which library you are using for the encryption:

      GSKit uses ".sth'

      OpenSSL uses ".stl" (can be created with the new "onkstash" tool)


    I'm not sure pkcs12 was supported in 14.10.FC1 so maybe that explains why the server will fails to load the .p12 file.  I don't think 4.50.FC4W1 will be able to use GSKit, the version you would have in the machine would be from 14.10.FC1 and the '$INFORMIXDIR/lib/libisi.so.1' library (which controls what encryption method to use) would be the OpenSSL one.

    I guess your options are upgrade IDS to 14.10.FC4W1 or use a previous version of CSDK (e.g. 4.50.FC3)



    ------------------------------
    Javier Sagrera
    ------------------------------



  • 12.  RE: Major Issues with Windows CSDK4.50.FC4W1

    Posted Mon August 17, 2020 10:31 AM
    Thanks, Javier!

    Yes, seen it and just responded.

    TIA, Martin

    --






  • 13.  RE: Major Issues with Windows CSDK4.50.FC4W1

    Posted Mon August 17, 2020 10:14 AM
    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.






  • 14.  RE: Major Issues with Windows CSDK4.50.FC4W1

    Posted Mon August 17, 2020 11:30 AM
    Edited by Sebastien FLAESCH Mon August 17, 2020 11:40 AM
    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
    ------------------------------



  • 15.  RE: Major Issues with Windows CSDK4.50.FC4W1

    Posted Mon August 17, 2020 11:58 AM
    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.






  • 16.  RE: Major Issues with Windows CSDK4.50.FC4W1

    Posted Mon August 17, 2020 12:15 PM
    Sorry "-ca true -sigalg SHA256WithRSA" options did not help...

    ------------------------------
    Sebastien FLAESCH
    ------------------------------



  • 17.  RE: Major Issues with Windows CSDK4.50.FC4W1

    Posted Mon August 17, 2020 02:02 PM
    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.






  • 18.  RE: Major Issues with Windows CSDK4.50.FC4W1

    Posted Mon August 17, 2020 02:39 PM

    Yes, I have OpenSSL 1.1 installed on my Debian 10:

    informix@toro:/opt3/dbs/ifx/CSDK-4.50.FC4W1$ ls -l lib/libisi*
    lrwxrwxrwx 1 informix informix 19 Aug 13 15:45 lib/libisi.so.1 -> ./libisi_o11.so.1.2
    -rwxr-xr-x 1 informix informix 201136 Aug 13 15:45 lib/libisi_o10.so.1.2
    -rwxr-xr-x 1 informix informix 203872 Aug 13 15:45 lib/libisi_o11.so.1.2
    -rwxr-xr-x 1 informix informix 204448 Aug 13 15:45 lib/libisi_oos.so.1.2

    informix@toro:/opt3/dbs/ifx/CSDK-4.50.FC4W1$ ldd -r lib/libisi_o11.so.1.2
    linux-vdso.so.1 (0x00007fffdaacb000)
    libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f75bbbea000)
    libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f75bbb58000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f75bb997000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f75bc121000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f75bb992000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f75bb971000)


    BTW I was wondering about the symbolic link libisi.so.1 ...
    I guess that lib is used by Informix binaries as a wrapper to OpenSSL APIs... correct guess?
    If I would like to use another OpenSSL version, would I have to change that symbolic link (or is this done by the installer)?
    Is this documented somewhere?

    Seb

    ------------------------------
    Sebastien FLAESCH
    ------------------------------



  • 19.  RE: Major Issues with Windows CSDK4.50.FC4W1

    Posted Tue August 18, 2020 04:44 AM
    Edited by Sebastien FLAESCH Tue August 18, 2020 04:51 AM