MQRC 2393: SSL initialization error

What it means

Before an MQ client can open a TLS channel, it loads its TLS support and opens its key repository, the file that holds its certificates and trusted CAs. 2393 means that step failed. IBM documents the code for AIX, Linux and Windows, where the C client uses IBM's GSKit. The call ends with MQCC_FAILED, and IBM's advice is short. Check that TLS is installed correctly and read the error logs.

The key repository is the most common problem. The client is told where it is through the MQSSLKEYR environment variable, the SSLKeyRepository setting in the SSL stanza of mqclient.ini, or the MQSCO structure on MQCONNX. MQ expects the path without the .kdb extension, so a value ending in .kdb points at a file that doesn't exist. When the client relies on a password stash file (.sth), it must sit next to the .kdb with the same stem name, or the repository can't be opened. File permissions that stop the application's user from reading either file give the same result.

Java applications usually report TLS failures as 2397 instead, with the JSSE exception attached. Some Java setups have still been reported with 2393, for example when a cipher suite couldn't be used.

Common causes

• The key repository path is wrong, or includes the .kdb extension when MQ expects the stem name only.
• The stash file (.sth) is missing, out of date, or has a different stem name from the .kdb.
• The application's user can't read the key repository or stash file.
• The TLS support files of the MQ client installation are missing or damaged, for example after a partial install or upgrade.
• The settings on MQCONNX (MQSCO, MQCD) ask for something the local TLS environment can't provide.

How to find the problem

1. Read the client error log (AMQERR01.LOG in the client's errors directory). It records why TLS initialisation failed, such as a key repository that couldn't be opened.
2. Check every place the key repository can be set. That means echo $MQSSLKEYR, the SSL stanza of mqclient.ini, and any MQSCO KeyRepository value in the code.
3. List the files and permissions, for example ls -l /var/mqm/ssl/client.*, and confirm both .kdb and .sth exist with the same stem.
4. Open the repository with runmqakm -cert -list -db client.kdb -stashed. If that fails, MQ can't open it either.

How to fix it

• Set the key repository path to the stem without the extension, for example /var/mqm/ssl/client.
• Recreate the stash file with runmqakm -keydb -stashpw -db client.kdb -pw ... if it is missing or stale.
• Give the application's user read access to the .kdb and .sth files.
• Repair or reinstall the MQ client if its TLS components are damaged.
• After fixing a queue manager's own key repository, run REFRESH SECURITY TYPE(SSL) so running channels pick up the change.

Technical reviewer: Albert Joseph, WND Software.

Last reviewed 2026-10-18 by the WND Software team. Written in our own words. For the full reference, check IBM’s MQ documentation for your version.