[UPDATE: No bug. PEBKAC error; bad file permissions were the culprit.]

IDS 14.10.FC5 on CentOS 7 x86_64

We recently switched from using GSKit/CSM key databases to OpenSSL/p12 key databases. Since then, when running locally on the host where the DB resides, regular users can still connect using client.p12/client.sth, but PAM users who attempt to connect get :

$ ls -la $INFORMIXDIR/etc/client.???
-rw-------. 1 informix informix 4798 Jan 15 21:10 /informix/products/TJGTEST/etc/client.p12
-rw-------. 1 informix informix 193 Jan 15 21:10 /informix/products/TJGTEST/etc/client.sth
$ echo "SELECT COUNT(*) FROM systables;" | dbaccess tjgdb

28014: Secure Sockets Layer error: cannot initialize GSKit environment/GSK_ERROR_BAD_KEYFILE_PASSWORD (GSK.​

If I switch back to client.kdb/client.sth, it works fine:

$ ls -la $INFORMIXDIR/etc/client.???
-rw-r--r--. 1 informix informix 88 Feb 6 2020 /informix/products/TJGTEST/etc/client.crl
-rw-r--r--. 1 informix informix 10088 Feb 6 2020 /informix/products/TJGTEST/etc/client.kdb
-rw-r--r--. 1 informix informix 88 Feb 6 2020 /informix/products/TJGTEST/etc/client.rdb
-rw-r--r--. 1 informix informix 193 Feb 6 2020 /informix/products/TJGTEST/etc/client.sth
$ echo "SELECT COUNT(*) FROM systables;" | dbaccess tjgdb

Database selected.



(count(*))

77

1 row(s) retrieved.



Database closed.​

This seems to only be the case for implicit local connections involving PAM users. Connecting remotely, or using dbaccess->Connection->Connect and manually typing the username and password also works.

I suspect this is a bug with the OpenSSL implementation.

I have a case open, TS004916260

------------------------------
TOM GIRSCH
------------------------------
#Informix

Derp. That was the problem all right. I hate it when I miss the obvious stuff!

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

Original Message:
Sent: Mon February 01, 2021 10:13 AM
From: Martin Fuerderer
Subject: OpenSSL Bug in 14.10.xC5?

Hi,

I noted, that your keystore files and password stash files have different file access rights:

- The *.kdb file and corresponding *.sth password stash files are readable for everybody.

  This normally is sensible for the client keystore, as the client keystore normally only

  contains the certificates for the server(s) it connects to, and those certificates are

  public - not containing any secret information.

- Whereas your *.p12 keystore file and corresponding *.sth password stash file have
  read access for user informix only.

Given this difference, I'm not sure, how any client user not being user informix would

be able to use the *.p12 keystore (or it's corresponding password stash file)?

Please check if enabling read permission of the keystore and stash file for everyone

can solve the problem.

(While for the server's keystore and password stash file we recommend the file

permission setting of read and write access exclusively for user informix, we do

not recommend this for the client keystore and its corresponding password stash file.
With this regard, there is no difference between a client keystore located on the same

machine where the database server is running, or on a remote client machine.)

Regards, Martin

--

Martin Fuerderer

Software Engineer, Software Development

HCL Technologies Ltd.

Frankfurter Ring 17

80807 Munich, Germany

www.hcltech.com

::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.

---