Re: Error: Could not locate TLS/SSL package
On Wed, Aug 17, 2022 at 12:16 PM Quanah Gibson-Mount
<quanah(a)fast-mail.org> wrote:
--On Wednesday, August 17, 2022 2:11 PM +0530 Vijay Maidarkar
<vmaidarkar(a)gmail.com> wrote:
Hi, please keep replies on the list.
> Find below answers.
>
> Where is it installed?
> $ which openssl
>
> /usr/local/bin/openssl
>
> $ ldd /usr/local/bin/openssl
> linux-vdso.so.1 => (0x00007fff931e6000)
> libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007f7f7a570000)
> libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f7f7a087000)
> libdl.so.2 => /lib64/libdl.so.2 (0x00007f7f79e83000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f7f79c67000)
> libc.so.6 => /lib64/libc.so.6 (0x00007f7f79899000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f7f7a802000)
>
> How was it installed?
> I've downloaded the archive & done compilation from below cmds.
>
> $ ./config
> $ make
> $ make install
There are other options you should be using for OpenSSL. At minimum,
you probably want enable-ec_nistp_64_gcc_128 on x86_64. Also see
https://wiki.openssl.org/index.php/Compilation_and_Installation#Configure...
.
So, you built it yourself so there will be no development package.
I'm not
sure why you built such an ancient version of OpenSSL (you listed OpenSSL
1.1.1g when 1.1.1q is the most recent), since it's vulnerable to multiple
critical CVEs.
I'd strongly advise using the packages from EPEL if you insist on staying
on CentOS7 (which is near end of life).
If you are going to use your own OpenSSL build, I can't emphasize enough
the importance of using a current release. Since you're doing this in an
unpackaged way, maintenance is going to be a nightmare.
Since you've built it yourself into its own location, you have to tell the
configure script where to find the development headers, like:
CPPFLAGS="/usr/local/include" LDFLAGS="-L/usr/local/lib
-Wl,-rpath,/usr/local/lib" ./configure ...
+1 for the RPATH.
Linux (and other OSes) have a (mis)feature of building against one
version of a library, and runtime linking against another version of
the library. Be sure to specify the RPATH to avoid the bug.
(If you want to see the effects of linking against the wrong library
at runtime, see
https://www.openwall.com/lists/oss-security/2020/07/20/1).
Nowadays on Linux you should specify a RUNPATH, not a RPATH. The
RUNPATH allows LD_LIBRARY overrides to search paths. It is recommended
by the folks who write the runtime loaders. The options you need are:
* -Wl,-rpath,<lib path> (enables RPATH)
* -Wl,--enable-new-dtags (enables RUNPATH)
Jeff