ALERT: Some images may not load properly within the Knowledge Base Article. If you see a broken image, please right-click and select 'Open image in a new tab'. We apologize for this inconvenience.

XCOM ssl transfer fails: XCOMU0298E Txpi 701 & invalid EyeCatcher (XCOMU0469E)

book

Article ID: 196418

calendar_today

Updated On:

Products

XCOM Data Transport XCOM Data Transport - Linux PC

Issue/Introduction

Currently using XCOM to transfer files successfully to a remote system over the non-secure interface on port 8044. However, now have a requirement to send these files over the secure interface on port 8045. Both local and remote systems are running XCOM r11.6 SP00 for Linux.
Have imported the ssl certificates and mapped in the config files on both servers. However, when run this command to the remote server it fails per errors below:

/opt/CA/XCOM/bin/xcomtcp -t -c1 -f LOCAL_FILE=/share/gs/dir1/dir2/dummy.txt REMOTE_FILE=/tmp/xcom/dummy.txt FILE_OPTION=REPLACE PASSWORD.ENCRYPTED="..." PORT=8045 PROTOCOL=TCPIP REMOTE_SYSTEM=hostname USERID=xxxx QUEUE=NOSECURE_SOCKET=YES

===
2020/07/20 16:40:57 TID=002000 [/share/gs/dir1/dir2/dummy.txt --> /tmp/xcom/dummy.txt at hostname]
    XCOMU0029I Locally initiated transfer started.

2020/07/20 16:40:57 TID=002000
    #XCOMU0298E Unable to allocate remote transaction program: Txpi  701: Received remote data block at 0X7FFC81FE1E90 starting with invalid EyeCatcher 0X2358434F (#XCOMU0469E xcom); expected 0x7f0298765432.
===

Environment

Release : 11.6
Component : CA XCOM Data Transport for Linux PC

Resolution

1. For the initial reported problem, the xcom.log showed "Missing or invalid '/usr/spool/xcom/config/configssl.cnf'" where "/usr/spool/xcom/config/" is a symbolic link to "/opt/CA/xcom/config"
===
2020/07/20 22:03:50 TID=002004 PRG=xcomtp PID=28983 IP=remote_host_name PORT=8045
    XCOMU0780E Txpi  307: TxpiSSLConfig Failed msg = <ConfigSSL: Missing or invalid </usr/spool/xcom/config/configssl.cnf> file.> value = 0: 

2020/07/20 22:03:50 TID=002004
    #XCOMU0298E Unable to allocate remote transaction program: Txpi  701: Received remote data block at 0X7FFC579D7D50 starting with invalid EyeCatcher 0X2358434F (#XCOMU0469E xcom); expected 0x7f4898765432.
===
After checking required XCOM symbolic links, the configssl.cnf file location and its content, that problem went away.

2. New error now seen in the local xcom log file after new transfer attempt to the remote server:
"XCOMU0780E Txpi  308: TxpiInitSSL Failed msg = 'error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt' value = 0:"
From openssl s_client tests done by support to local server using the provided ssl files, it appeared the certificate was pass phrase protected.
Add the pass phrase to the [PASSWORD] section of the local configssl.cnf file for both INITIATE_SIDE & RECEIVE_SIDE and test a loopback transfer on the local server i.e.
===
[PASSWORD]
INITIATE_SIDE = password
RECEIVE_SIDE  = password
===
The loopback test was successful.

3. Using #2, a transfer test to the remote server shows a new error:
"XCOMU0780E Txpi  308: TxpiInitSSL Failed msg = <error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number> value = 4294967295:"
Support requested this openssl test be executed to the remote server :
"openssl s_client -connect remote_hostname:8045 -ssl3 -cert /opt/CA/XCOM/ssl/certs/clientcert.pem -key /opt/CA/XCOM/ssl/private/clientkey.pem -showcerts -status -msg < /dev/null > openssl_ssl3.out 2>&1"
It was successful but returned "Cipher is (NONE)" amd " Cipher    : 0000"
There was also an error: "140443818207120:error:1408D177:SSL routines:ssl3_get_key_exchange:bad dh g value:s3_clnt.c:1786:"
Per this KB article: After upgrade CA XCOM server OS from RHEL 6.9 to 7.7, secure socket ping fails with XCOMU0298E and XCOMU0780E handshake failure
Change remote configssl.cnf to have the [RSAKEY] value "RECEIVE_SIDE" set to YES instead of the default NO, so that RSA is used instead of Diffie Hellman (RSA is more secure) i.e.
===
# Mandatory, YES/NO (if NO, DH will be used)
[RSAKEY]
RECEIVE_SIDE = NO
===
The ssl handshake was then successful.