News, tips, partners, and perspectives for the Oracle Solaris operating system
-
Technologies / Oracle Solaris 11
July 8, 2020
Managing Multiple OpenSSL Versions and Modes on a Single System
Guest Author: Vladimír Kotal
Supported OpenSSL Versions in Oracle Solaris
Oracle Solaris 11.4 Support Repository Update (SRU) 21 delivers both the OpenSSL 1.0.2 and OpenSSL 1.1.1 versions. These versions are not binary compatible, so software that is compiled with OpenSSL headers and linked with OpenSSL libraries from one version cannot run with the OpenSSL libraries from the other version.
The goal of this article is to clear potential confusion with regards to FIPS 140-2 support (FIPS) and the coexistence of applications linked with 1.0.2 and 1.1.1 on the same system.
The following describe the properties of each version:
-
OpenSSL 1.0.2: Is delivered as two sets of libraries for FIPS and non-FIPS in the library/security/openssl/openssl-fips-140 package and library/security/openssl package, respectively.
The FIPS mode, or flavor, of OpenSSL in Oracle Solaris is distributed with a FIPS Object Module (FOM) that is derived from the original OpenSSL FOM, and you can view its certificate. To see the differences between the original OpenSSL FOM and derived Oracle FOM, see the Oracle OpenSSL FOM README file.
The FIPS and non-FIPS OpenSSL 1.0.2 libraries are binary compatible so that any application compiled and linked with OpenSSL 1.0.2 can start with either version.
-
OpenSSL 1.1.1: Oracle Solaris delivers OpenSSL 1.1.1 in the pkg:/library/security/openssl-11 package, which might not be installed by default.
Unlike OpenSSL 1.0.2, OpenSSL 1.1.1 does not include a FIPS 140-2 mode. The OpenSSL project intends to produce a FIPS 140-2 certified OpenSSL with OpenSSL 3.0, see the OpenSSL project blog.
Switching Between OpenSSL Modes and Versions
You can switch between OpenSSL modes and between OpenSSL versions using by IPS openssl mediator. Note that the mediator switches both the runtime and the compilation environment. The runtime environment refers to binaries such as /usr/bin/openssl, scripts and symbolic links to libraries such as /lib/libcrypto.so.1.0.0.
The compilation environment refers to the /usr/include/openssl symbolic link to header files and to the pkg-config files in /usr/lib/{32,64}/pkgconfig.
-
OpenSSL 1.0.2: Use the openssl IPS mediator to switch between the FIPS and non-FIPS OpenSSL 1.0.2 modes.
-
OpenSSL 1.1.1:: Introduces new openssl mediator value default@1.1. This value switches the runtime and the compilation environments to OpenSSL 1.1.1. If FIPS was previously enabled for OpenSSL 1.0.2, its runtime environment is switched to the non-FIPS mode.
To compile an application with OpenSSL 1.1.1, you do not need to switch the mediator. See "Compiling and Linking Programs With the OpenSSL 1.1.1 Headers and Libraries."
Compiling and Linking Programs With the OpenSSL 1.1.1 Headers and Libraries
Only a few Oracle Solaris programs are linked with OpenSSL 1.1.1. However, because TLS 1.3 is required, and not present in OpenSSL 1.0.2, it is likely that more and more programs will need to be linked with OpenSSL 1.1.1 in the future.
To link a program with OpenSSL 1.1.1, ensure that the build procedure for your program points to the OpenSSL 1.1.1 header files and libraries. Note that you do not need to change the mediator value.
After you install the openssl-11 package, you can compile programs by including the pkg-config program on the command line. Here is example for 64-bit program:
$ gcc -m64 `PKG_CONFIG_PATH=/usr/openssl/1.1/pkgconfig/64 pkg-config --cflags libcrypto` \
openssl-test.c \
`PKG_CONFIG_PATH=/usr/openssl/1.1/pkgconfig/64 pkg-config --libs libcrypto
libssl`
The pkg-config method always succeeds in compiling and linking a program with up-to-date information even when the underlying paths and data change.
Of course, you can also compile programs without using the pkg-config program, as shown by the following command:
$ gcc -m64 -I /usr/openssl/1.1/include openssl-test.c \
-L/usr/openssl/1.1/lib/64 -lcrypto -lssl
Note that you do not need to supply a runtime path for the OpenSSL libraries because both the libcrypto.so and libssl.so libraries in the /usr/openssl/1.1/lib/ directory have correctly set the SONAME attribute value in the dynamic section of the ELF.
Ensure that both the OpenSSL 1.1 include and library paths are prepended to the default search paths.
For example, using the --with-ssl=/usr/openssl/1.1 option to specify the OpenSSL installation directory (/usr/openssl/1.1) for building the curl program is insufficient.
curl Example
The curl code constructs the CPPFLAGS environment variable and specifies /usr/include before /usr/openssl/1.1/include in the search path.
Similarly, curl attempts to access the OpenSSL 1.0.2 header files in the /usr/include/openssl directory instead of the OpenSSL 1.1.1 header files.
Thus, you must pass the following modified values of the CPPFLAGS and LDFLAGS environment variables to the configuration script:
LDFLAGS += $(shell PKG_CONFIG_PATH=/usr/openssl/1.1/pkgconfig/64 pkg-config \
--libs-only-L libcrypto)
CPPFLAGS += $(shell PKG_CONFIG_PATH=/usr/openssl/1.1/pkgconfig/64 pkg-config \
--cflags libcrypto)
Avoid Mixing Different OpenSSL Libraries in a Single Program
It is important to avoid mixing multiple different versions of OpenSSL libraries in one program. In the curl example, it is not sufficient to recompile and relink only the curl binary. You must also recompile and relink the libraries that curl is dependent on and which depend on OpenSSL, such as libssh2 or libldap_r.