The Secure Socket Layer (SSL) standard ensures secure connections between endpoints. To facilitate that, we can use the openssl tool for configuring the OpenSSL libraries that implement the standard. In fact, openssl also has many other uses like SSL certificate management, self-signed certificate creation, and key generation. Because of its wide applications, the OpenSSL toolkit and library are part of many software packages.
In this tutorial, we discuss the installation of OpenSSL and some problems we might encounter when we attempt it alone or as part of another installation. First, we see how to install OpenSSL. After that, we go through different ways to try and fix or work around configuration and installation problems.
2. Installing OpenSSL
As with most packages and software, installing the OpenSSL library and toolkit can happen in several ways.
2.1. Package Manager
$ apt install openssl
However, this method often provides the latest repository version of the OpenSSL toolkit without any development tools. Consequently, this might differ from the latest stable version and is usually older than the latest one overall.
$ ./Configure --prefix=/usr/local/ssl --openssldir=/usr/local/ssl '-Wl,--enable-new-dtags,-rpath,$(LIBRPATH)'
After the configuration is complete, we can usually issue run make to build and install:
$ make && make install
At this point, we should have a working installation of OpenSSL. However, in certain conditions, this process can result in issues.
3. General Compilation and Configuration Troubleshooting
As many packages that include others build them from source, the actual building process can cause problems. Thus, let’s explore some general fixes and workarounds for problems during compilation and configuration.
3.1. Build Tools
To compile or build anything under Linux, we need the proper tooling. Most often, this includes the build-essential meta-package:
$ apt-get install build-essential
The build-essential package is a collection of compilers and utilities that facilitate and help with the building and compilation of most software.
3.2. Kernel Headers
$ apt-get install linux-headers-$(uname -r)
In this case, we use the idiomatic kernel header package name prefix linux-headers- along with the current version we already have as output by uname with its -r option.
In addition to incorrect or missing packages, problems often arise due to improper environment settings when configuring packages for installation. In particular, several variables that can affect this process:
- LIBRARY_PATH – library path during compilation
- LD_LIBRARY_PATH – library path during runtime
- LDFLAGS – compiler options for linking
- CFLAGS – general C compiler options
While the specific settings and values vary per platform and system, we can unset these variables to try and remedy errors with package builds:
$ unset LIBRARY_PATH $ unset LD_LIBRARY_PATH $ unset LDFLAGS $ unset CFLAGS
Again, the particular modifications depend on the environment.
The pkg-config utility is just a helper for the compilation of libraries and applications. In essence, it dynamically includes the options we need for a particular build to avoid adding those manually in a static manner.
Although it should just be a helper tool, installers sometimes depend on pkg-config for their proper function. In particular, due to the settings, we rely on it to insert, it may happen that hard dependencies are skipped.
To clarify, hard dependencies are required for an installation to work. Meanwhile, soft dependencies aren’t necessary for the basic functionality but usually introduce features.
For example, let’s say some build options involve the setting of library paths:
$ ./configure CFLAGS='-I/usr/custom/include'
If pkg-config doesn’t set these via its respective –cflags option, we might miss the custom path and not have access to components already available on the system. Of course, this is valid for other build tools as well.
4. OpenSSL Configuration Remedies
While OpenSSL alone isn’t often the direct source of problems, its inclusion in various installations and packages may cause them. Let’s take two examples:
Since these packages require it, we should have a working OpenSSL installation. However, despite having one, we might still experience problems when attempting to build or install either of the above:
- Build dependency: Please install the openssl library (with development headers)
- Could not autodetect OpenSSL support.
Such errors can come in different forms and for different reasons
If the general fixes we already discussed don’t help, we can also try some OpenSSL-specific remedies.
4.1. OpenSSL Headers
While OpenSSL has a defined functionality, its applications vary. Because of this, OpenSSL can come in different forms:
- deployable packages
- source code
- runtime components
Depending on our needs, we might require one or another part of the OpenSSL ecosystem.
For instance, many packages include components for development and building. Furthermore, unlike distributions such as ArchLinux, openssl on Debian doesn’t include libssl-dev, the development headers. Thus, we might need to install those also:
$ apt-get install libssl-dev
Also, the package name itself can vary on different platforms (yum install openssl-devel, apt-get install libssl-dev, apt-get install libssl1.0, apt-get install libssl1.1).
Only once we have the necessary components, can we build and install OpenSSL for the relevant application.
4.2. Skip OpenSSL Installation
If package installation or environment configuration isn’t an option, some installers enable users to avoid the relevant OpenSSL components.
For example, we can compile NodeJS while including the –without-ssl switch:
$ ./configure --without-ssl
This way, no attempt is made to get or install OpenSSL. Of course, doing so can break components or the resulting deployment.
In this article, we talked about OpenSSL deployment and dependency problems and how we might be able to remedy them.
In conclusion, although OpenSSL is a well-defined idea, its components vary, and it may be difficult to establish which one is required for a given installation and where it should be located.