Resolving libssl.so.1.1 Missing Issues in Ubuntu 22.04: OpenSSL Version Compatibility Solutions

Problem Background and Root Cause

In Ubuntu 22.04 LTS, the system's default OpenSSL library was upgraded from the 1.1.x series to version 3.0.x. This significant change has caused compatibility issues for numerous applications that depend on the older OpenSSL version. The specific manifestation is the inability to locate the libssl.so.1.1 shared library file during runtime, resulting in the error: ImportError: libssl.so.1.1: cannot open shared object file: No such file or directory.

System-Level Solution

The most direct and effective solution is to install the compatible libssl1.1 package. The Ubuntu official repository still provides version 1.1 library files compatible with 22.04, which can be installed using the following commands:

wget http://nz2.archive.ubuntu.com/ubuntu/pool/main/o/openssl/libssl1.1_1.1.1f-1ubuntu2.22_amd64.deb
sudo dpkg -i libssl1.1_1.1.1f-1ubuntu2.22_amd64.deb

The advantages of this approach include:

• Maintaining consistency with system package management
• No need to modify application code or configuration
• Official Ubuntu maintenance ensures security
• Automatic handling of dependencies and version conflicts

Custom Library Path Approach

As an alternative solution, developers can choose to manually compile OpenSSL 1.1.x and control library loading paths through environment variables:

mkdir -p $HOME/opt/lib
cd $HOME/opt
wget https://www.openssl.org/source/openssl-1.1.1o.tar.gz
tar -zxvf openssl-1.1.1o.tar.gz
cd openssl-1.1.1o
./config --prefix=$HOME/opt/openssl-1.1.1o && make && make test
cp -r .libs/* $HOME/opt/lib/
export LD_LIBRARY_PATH=$HOME/opt/lib:$LD_LIBRARY_PATH

This method is suitable for scenarios such as:

• Development environments requiring multiple OpenSSL versions
• Production environments with strict restrictions on system-level installations
• Special applications requiring precise version control

Technical Principle Deep Analysis

The dynamic linking mechanism for shared libraries in Linux systems is implemented through ld.so. When an application runs, the dynamic linker searches for shared libraries in the following order:

1. Paths specified by the LD_LIBRARY_PATH environment variable
2. Library paths cached in /etc/ld.so.cache
3. Default system library paths (/lib, /usr/lib)

OpenSSL 3.0 introduces API incompatibility. Although it provides a compatibility layer, some applications still require specific 1.1.x version symbols. The major version number change in .so.1.1 indicates ABI incompatibility, which is the fundamental cause of linking failures.

Impact on Python Virtual Environments

Library dependencies can become more complex in Python virtual environments. While virtual environments create isolated Python interpreters and library paths, system-level shared library dependencies still persist. When using virtualenv or venv to create environments:

import ssl
print(ssl.OPENSSL_VERSION)

This code displays the OpenSSL version linked by the current Python interpreter. If the virtual environment was created on an older system, upgrading the system may require recreating the virtual environment or installing compatible libraries.

Best Practice Recommendations

For different usage scenarios, the following solutions are recommended:

• Regular Users: Use system package manager to install libssl1.1 - the simplest and most reliable method
• Developers: Consider updating applications to support OpenSSL 3.0, or use containerization technologies to isolate dependencies
• System Administrators: Prioritize system package management solutions in production environments to ensure security updates

Troubleshooting Procedure

When encountering shared library issues, follow these diagnostic steps:

1. Use ldd command to check application library dependencies: ldd /path/to/application
2. Verify library file existence: find / -name libssl.so.1.1 2>/dev/null
3. Check current library loading paths: echo $LD_LIBRARY_PATH
4. Examine system library cache: ldconfig -p | grep libssl

Long-term Compatibility Considerations

As OpenSSL 3.0 becomes mainstream, developers are advised to:

• Gradually migrate applications to OpenSSL 3.0 API
• Test compatibility across different OpenSSL versions in CI/CD pipelines
• Use dynamic version detection and conditional compilation to handle API differences
• Consider modern TLS library alternatives