XCOM CAPKI (OpenSSL) version compatibility ("bad dh g value")
search cancel

XCOM CAPKI (OpenSSL) version compatibility ("bad dh g value")

book

Article ID: 234309

calendar_today

Updated On:

Products

XCOM Data Transport XCOM Data Transport - Linux PC XCOM Data Transport - Windows

Issue/Introduction

XCOM and AutoSys both use CAPKI (which uses OpenSSL) for SSL communication.

We have multiple versions of XCOM and AutoSys. In most cases, they go hand-in-hand i.e. XCOM transfers are automated using AutoSys.
We are upgrading AutoSys to r12 SP1 but it breaks XCOM SSL communication.
That is because both share the CAPKIHOME directory and AutoSys r12 SP1 upgrades CAPKI to 5.2.6.

After the AutoSys upgrade:
The CAPKI versions are as below:
# cat /opt/CA/SharedComponents/CAPKI/CAPKI5/Linux/amd64/64/.installdb
CurrentVersion 5.2.6
CAXCOM 5.1.0
WAAE 5.2.6

Execute loopback ping:
xcomtcp –ping REMOTE_SYSTEM=127.0.0.1 
Error returned is "bad dh g value" 

After CAPKI 5.1.0 is restored for XCOM CAPKIHOME, the same command is successful.

We have so far seen this issue affirmatively with the following XCOM 11.6 SP01 64bit UNIX/Linux versions:
CA XCOM Data Transport r11.6 20070 SP01 64bit (for <no SNA support>)
CA XCOM Data Transport r11.6 17021 SP01 64bit (for <no SNA support>)
CA XCOM Data Transport r11.6 16083 SP01 64bit (for <no SNA support>)

Environment

  • XCOM™ Data Transport® for Windows 11.6
  • XCOM™ Data Transport® for UNIX/Linux PC 11.6
  • XCOM™ Data Transport® for Linux PC 12.0

Cause

The default configssl.cnf is as follows:
===
# Mandatory, YES/NO (if NO, DH will be used)
[RSAKEY]
RECEIVE_SIDE = NO

# Optional (for RSA NO, see above). If RSA NO and DH files empty,
#  then internal program tables will be used.
[DH]
DH_512_RECEIVE_SIDE  = 
DH_1024_RECEIVE_SIDE = 
DH_2048_RECEIVE_SIDE = 
DH_4096_RECEIVE_SIDE = 
===
The XCOM internal program tables mentioned above use DH512 if the "[DH]" file parameters are not set as in the above defaults.
When Autosys upgrades CAPKI to 5.2.6 it uses a later OpenSSL 1.0.2t that does not support DH512 because of its insecure nature and that incompatibility results in the error "bad dh g value".

Resolution

To circumvent the CAPKPI 5.2.6 incompatibility, XCOM configssl.cnf file changes are required as follows:

  1. EITHER:
    Change the [CIPHER] INITIATE_SIDE section to exclude Diffie–Hellman (DH) (no change is required for RECEIVE_SIDE) i.e.
    [CIPHER]
    Current:
    INITIATE_SIDE =  ALL:!ADH:!LOW:!EXP:MD5:@STRENGTH
    Change to:
    INITIATE_SIDE = ALL:!DH:!LOW:!EXP:!MD5:@STRENGTH
    NOTE:  ADH (Anonymous DH) is a subset of DH, so updating "!ADH" to "!DH", rules out both ADH and DH.
  2. OR: 
    Change the RSAKEY section to use RSA i.e.
    [RSAKEY]
    RECEIVE_SIDE = YES

    NOTE: When the RSAKEY parameter is set to "YES", it will force the partner to use ciphers that use the RSA Key exchange algorithm. When it is set "NO", it means that it has no specific priority and it can accept both DH and RSA from its partner. 


    NOTES:
  • Using option 1 is suggested because it is an INITIATE_SIDE change that requires no additional change on any destination/remote XCOM partners. As option 2 is a RECEIVE_SIDE change, it will need to be done on all destination/remote XCOM partners.
  • Updating configssl.cnf does NOT REQUIRE a restart of the XCOM service because that file is read for every transfer.
  • Going forward the XCOM for Linux 12.0 has been released with CAPKI version 5.2.8 (OpenSSL 1.0.2zb) and a modified version of configssl.cnf file which uses option 1.

Additional Information

1. USAGE EXAMPLES:
Starting with Linux 12.0, XCOM captures the cipher description in the trace file once the SSL Handshake is complete. Some trace excerpts below from various scenarios: 

Scenario 1: 
Modify "!ADH" to "!DH" on INITIATE_SIDE, RSAKEY section is unchanged:
E - catoossl.c(3052): do_server_accept: SSL_CIPHER_get_name <AES256-GCM-SHA384>.
E - catoossl.c(3055): do_server_accept: SSL_CIPHER_get_bits 256.
E - catoossl.c(3059): do_server_accept: SSL Version: TLSv1.2.
E - catoossl.c(3069): do_server_accept: SSL Cipher description: AES256-GCM-SHA384       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(256) Mac=AEAD

Scenario 2: 
Modify RECEIVE_SIDE=YES under RSAKEY and "!ADH" to "!DH" on INITIATE_SIDE. The result will be the same as above:
E - catoossl.c(3052): do_server_accept: SSL_CIPHER_get_name <AES256-GCM-SHA384>.
E - catoossl.c(3055): do_server_accept: SSL_CIPHER_get_bits 256.
E - catoossl.c(3059): do_server_accept: SSL Version: TLSv1.2.
E - catoossl.c(3069): do_server_accept: SSL Cipher description: AES256-GCM-SHA384       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(256) Mac=AEAD

Scenario 3: 
Modify RECEIVE_SIDE=YES under RSAKEY and CIPHER section unchanged. The result will be the same as above: 
E - catoossl.c(3052): do_server_accept: SSL_CIPHER_get_name <AES256-GCM-SHA384>.
E - catoossl.c(3055): do_server_accept: SSL_CIPHER_get_bits 256.
E - catoossl.c(3059): do_server_accept: SSL Version: TLSv1.2.
E - catoossl.c(3069): do_server_accept: SSL Cipher description: AES256-GCM-SHA384       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(256) Mac=AEAD

Scenario 4: 
Another option is to specify DH files. This will allow usage of stronger DH keys if using RSA is not desired. With CIPHER section, RSAKEY sections unchanged, and DH section updated to set DH_1024 or above the result is:
E - catoossl.c(3052): do_server_accept: SSL_CIPHER_get_name <DHE-RSA-AES256-GCM-SHA384>.
E - catoossl.c(3055): do_server_accept: SSL_CIPHER_get_bits 256.
E - catoossl.c(3059): do_server_accept: SSL Version: TLSv1.2.
E - catoossl.c(3069): do_server_accept: SSL Cipher description: DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD


2. ADDITIONAL NOTES:
a. If it is preferred to use DH then the steps in the Linux 12.0 documentation to use higher bit DH than 512 are also valid for 11.6 i.e.
XCOM Data Transport for UNIX/Linux 12.0 > Using > Set Up TLS/SSL Mode > Use DH Key Exchanges for TLS/SSL Communication
NOTE: Per option 2 above, as this is a RECEIVE_SIDE change, it will need to be done on all destination/remote XCOM partners.

b. XCOM for Windows 11.6 SP03 patch LU03588 upgraded OpenSSL 1.0.2d to 1.0.2j which is the last OpenSSL version to support DH512. That is why similar a warning note and steps to use higher bit DH were given at the end of that PTF installation although not yet mandatory.

NOTE:
Up to and including r11.6 SP02, XCOM for Windows also used CAPKIHOME and the behaviour was in sync with all Linux/Unix versions.
From 11.6 SP03 64bit, XCOM for Windows no longer used CAPKI and had its own OpenSSL library files libeay32.dll and ssleay32.dll which were updated by the above patch. So SP03 GA and later patches would not be directly impacted by any AutoSys/CAPKI upgrade. However in patch LU06617 ("CVE-2022-0778 possible infinite loop") which upgrades OpenSSL to 1.0.2ze, SP03 reverted to using CAPKI.
With XCOM for Linux 11.6, CAPKI Version 5.2.0 (OpenSSL 1.0.2j) would be the last version that works successfully without DH key compatibility issues.

c. In the short term if it is not feasible or considered to risky to change the concfigssl.cnf then a workaround would be to perform these steps before the AutoSys upgrade:
 - Copy the CAPKI directory being used by XCOM, according to parameter CAPKIHOME in the xcom.glb file, and store it in a new location.
 - Update the parameter CAPKIHOME in xcom.glb to point to that new location and restart the XCOM service.
Here is an example Linux script which can be used to automate that complete step sequence:
===
#!/bin/bash
source /etc/profile
source /etc/profile.CA
if [[ -z "$XCOM_HOME" ]]; then
   echo "XCOM_HOME is Empty, exiting"
   exit 1
elif [[ -z "$CASHCOMP" ]]; then
   echo "CASHCOMP is Empty, exiting"
   exit 1
fi
cp -p $XCOM_HOME/config/xcom.glb $XCOM_HOME/config/xcom_`date -Iseconds`.glb
cp -pr $CASHCOMP/CAPKI $XCOM_HOME
sed -i "s%CAPKIHOME=$CASHCOMP%CAPKIHOME=$XCOM_HOME%" $XCOM_HOME/config/xcom.glb
xcomd -s
xcomd
exit $?
===

Powered by Wolken Software