We are currently using XCOM to transfer files successfully to a remote system over the non-secure interface on port 8044. However, we 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.
We have currently imported the ssl certificates and mapped in the config files on both servers. However, when we 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.
Release : 11.6
Component : CA XCOM Data Transport for Linux PC
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=vpl00001757.privatecloud.prod.au.internal.cba 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.
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)
RECEIVE_SIDE = NO
The ssl handshake was then successful.