The CSP client installs fine on RHEL6 and CentOS6, but SCSP IPS Agent wouldn't start and generates this error: /usr/lib64/libssl.so.1.0.0 doesn't exist.

book

Article ID: 158879

calendar_today

Updated On:

Products

Critical System Protection Critical System Protection Client Edition Data Center Security Server Advanced

Issue/Introduction

This is a SCSP IPS Agent symlink issue with newly released versions of openssl on RHEL6 & CentOS6, creating SSL library errors. The IPS daemon is looking for (libssl.so.1.0.0) based on this symlink in IPS/binhome dir (/usr/products/Symantec/scspagent/IPS/bin/libssl.so.6 -> /usr/lib64/libssl.so.1.0.0). creating error: /usr/lib64/libssl.so.1.0.0 doesn't exist.

The error is caused by the fact that the CSP symlink libssl.so.6 is linking to openssl library libssl.so.1.0.0 and  the Openssl library, that is installed on RHEL6 & CentOS6, is a newer version of Openssl library.

 In the illustration of issue below, the new Openssl library is libssl.so.1.0.1e.

[[email protected]]# /etc/init.d/sisipsagent restart
SCSP IPS Agent is not running
Error starting SCSP IPS Agent
[[email protected]]# /etc/init.d/sisidsagent restart
Stopping SCSP IDS Agent (PID 857)..
SCSP IDS Agent stopped successfully after 5 seconds
SCSP IDS Agent started successfully (PID 15460)
[[email protected]]# /etc/init.d/sisipsutil restart
Stopping SCSP Util Service (PID 951).
SCSP Util Service stopped successfully after 1 seconds
SCSP Util Service started successfully (PID 15535)
[[email protected]]#

[[email protected]]# tail /var/log/scsplog/sisips.err
/usr/products/Symantec/scspagent/IPS/bin/sisipsdaemon: error while loading shared libraries: libssl.so.6: cannot open shared object file: No such file or directory

ls -l /usr/products/Symantec/scspagent/IPS/bin/libssl.so.6
lrwxrwxrwx 1 sisips sisips 26 Dec 30 14:23 /usr/products/Symantec/scspagent/IPS/bin/libssl.so.6 -> /usr/lib64/libssl.so.1.0.0
ls -l /usr/lib64/libssl.so.1.0.0
ls: cannot access /usr/lib64/libssl.so.1.0.0: No such file or directory

[[email protected]]# find / -name "libssl*"
/usr/products/Symantec/scspagent/IPS/bin/libssl.so.6
/usr/lib64/pkgconfig/libssl.pc
/usr/lib64/libssl.so.10
/usr/lib64/libssl3.so
/usr/lib64/libssl.so.1.0.1e
/usr/lib64/libssl.so
[[email protected] v530315]#

Resolution

The workaround is to create Symbolic links to the libssl.so.1.0.1e and libcrypto.so.1.0.1e.

1. Check the libraries first:

ls -al /usr/lib64/libssl*
-rwxr-xr-x. 1 root root 221600 Aug 7 20:42 /usr/lib64/libssl3.so
lrwxrwxrwx 1 root root 16 Dec 2 04:33 /usr/lib64/libssl.so -> libssl.so.1.0.1e
lrwxrwxrwx 1 root root 16 Dec 2 04:33 /usr/lib64/libssl.so.10 -> libssl.so.1.0.1e
-rwxr-xr-x 1 root root 436984 Nov 22 12:20 /usr/lib64/libssl.so.1.0.1e


ls -al /usr/lib64/libcrypto*
lrwxrwxrwx 1 root root 19 Dec 2 04:33 /usr/lib64/libcrypto.so -> libcrypto.so.1.0.1e
lrwxrwxrwx 1 root root 19 Dec 2 04:33 /usr/lib64/libcrypto.so.10 -> libcrypto.so.1.0.1e
-rwxr-xr-x 1 root root 1946880 Nov 22 12:20 /usr/lib64/libcrypto.so.1.0.1e

2. Create Sym links

cd /usr/lib64

ln -s libssl.so.1.0.1e libssl.so.1.0.0
ln -s libcrypto.so.1.0.1e libcrypto.so.1.0.0

3. Verify sym links are created:

lrwxrwxrwx 1 root root 16 Jan 13 16:04 /usr/lib64/libssl.so.1.0.0 -> libssl.so.1.0.1e
lrwxrwxrwx 1 root root 19 Jan 13 16:05 /usr/lib64/libcrypto.so.1.0.0 -> libcrypto.so.1.0.1e

4. Restart IPS Daemon:
/etc/init.d/sisipsagent restart

5. Verify IPS daemon started

/etc/init.d/sisipsagent restart
SCSP IPS Agent is not running
SCSP IPS Agent started successfully (PID 15635)

ps -ef|grep csp
root 15460 1 0 2013 ? 00:04:33 /usr/products/Symantec/scspagent/IDS/bin/sisidsdaemon
sisips 15535 1 0 2013 ? 00:00:00 /usr/products/Symantec/scspagent/IPS/bin/sisipsutildaemon
sisips 15635 1 0 16:08 ? 00:00:00 /usr/products/Symantec/scspagent/IPS/bin/sisipsdaemon

IPS Daemon started fine after creating the necessary symlinks.