KB Article #180705

Issue with command nslookup

Problem

(libcrypto.so.1.0.0) Suse 12 Sp4


Transfer CFT 3.3.2


Error:

$ nslookup
nslookup: /soft/cft/home/lib/libcrypto.so.1.0.0: no version information available (required by /usr/lib64/libdns.so.169)
nslookup: /soft/cft/home/lib/libcrypto.so.1.0.0: no version information available (required by /usr/lib64/libisc.so.166)

ENGINE_by_id failed (crypto failure)

330 error:25070067:DSO support routines:DSO_load:could not load the shared library:dso_lib.c:233:

330 error:260B6084:engine routines:DYNAMIC_LOAD:dso not found:eng_dyn.c:467:

330 error:2606A074:engine routines:ENGINE_by_id:no such engine:eng_list.c:390:id=gost
(null): dst_lib_init: crypto failure


CFT user wants to use its own lib and it might not be compatible with Sles 12.4's libs

Resolution

It is related to the Suse implementation of OpenSSL : they add some symbol information that are not present in the default version (i.e. https://askubuntu.com/questions/830466/libcrypto-so-1-0-0-no-version-information-available-required-by-ssh).

As a result, the Suse libcrypto.so.1.0.0 is supposed to contain some version information, whereas the default libcrypto.so.1.0.0 (embedded in CFT) does not contain those.

But some executable (nslookup) expect those information. Unfortunately, nothing we can do on CFT side, except by modifying the OpenSSL implementation (which won't be FIPS valid, so we can't do that).

You can check this with the following command (CFT profile loaded) : locate libcrypto.so.1.0.0
There should be two results : one in CFT directory, one for the system.

This should be solved with the next OpenSSL version that should be available in CFT 3.6 (ETA April 2020).

Workaround:

env -i nslookup

or

LD_LIBRARY_PATH="" nslookup