※この記事は、個人技術ブログ CodeArchPedia.com の技術メモ（要約）です。

Ubuntuをアップグレードした後、特定のアプリケーションが起動せず、『libssl.so.1.1: cannot open shared object file: No such file or directory』というエラーが出てハマった経験がある。

原因はOSがOpenSSL 1.1から3.0へ移行したことで、古いライブラリが削除されたことにある。緊急対応と恒久対応の両面から、この依存性問題をどう乗り切ったかをまとめた。

何が起きたか（課題）

Ubuntu 22.04 LTS以降へ移行した後、これまで問題なく動いていたアプリケーションやツールで以下のエラーが頻発した。

実行ファイルが共有オブジェクトファイル libssl.so.1.1 をロードできない。
これは、動的リンカがシステム上から古いバージョンのOpenSSLライブラリを見つけられないため。
多くのサードパーティ製ツールが、まだOpenSSL 3.0系への対応が完了していないライブラリバージョンに依存していることが原因。

どう解決したか（概要）

解決策は、緊急で動作させるための『一時的解決策』と、根本的な『恒久解決策』の2つに分けた。

1. 一時的解決策：libssl1.1パッケージのインストール

緊急でサービスを復旧させるため、サポートが終了している可能性のある libssl1.1 パッケージを明示的にインストールするアプローチを取った。

これは apt install libssl1.1 コマンドを実行するだけで済むが、セキュリティリスクを伴うため、あくまで一時的な回避策として処理した。

2. 非推奨なシンボリックリンク作成

もう一つの短期的な方法は、システム上のOpenSSL 3.0ライブラリ（例: libssl.so.3）を、アプリケーションが要求する libssl.so.1.1 へシンボリックリンクを張ることだ。これは動的リンカをごまかす方法だが、APIの不整合により予期せぬクラッシュを引き起こすリスクが高い。

3. 恒久的な解決策：アプリケーションのOpenSSL 3.0対応

最も確実な方法は、依存アプリケーション自身をOpenSSL 3.0に対応させることだ。自社開発サービスの場合、libssl-dev をインストールし、ビルド設定（MakefileやCMake）を見直してリコンパイルすることで、最新のライブラリを参照するように修正した。

効果（Before/After）

一時的なパッケージインストールにより、問題の発生していたアプリケーションは即座に起動可能になった。恒久対応としてビルドを修正した後は、システム全体が最新のOpenSSLバージョンで動作するようになり、古いライブラリに依存する必要がなくなった。これにより、将来のOSアップデート時にも同様の問題で悩まされるリスクが解消された。

🚀 詳細な設定とコードはこちら

具体的なシンボリックリンクの設定コマンドや、ビルド時に必要な libssl-dev のインストール手順、環境変数の確認方法などの詳細なコードスニペットは元のブログで公開しています。

👉 libssl.so.1.1エラーの解決法｜UbuntuでのOpenSSLライブラリのトラブルシューティングガイド