※この記事は、個人技術ブログ 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 のインストール手順、環境変数の確認方法などの詳細なコードスニペットは元のブログで公開しています。