OpenSSL 3.0のサポートが9月に終わりました。Ubuntu 22.04やRHEL 9のサーバーは、いま何を確認すればいい？

こんにちは、インフラエンジニアのryuです。

2026年9月7日、OpenSSL 3.0の公開サポートが終了しました。

OpenSSLは、HTTPSをはじめとする多くのTLS通信を裏で支えている暗号ライブラリです。Webサーバー、メールサーバー、curl、Pythonなど、Linuxの上で動くかなりのソフトウェアがこれを使っています。

「サポート終了」と聞くと、すぐにアップグレードしないといけない気がしますよね。

ただ、OpenSSLの場合は少し事情が複雑です。OSに最初から入っているOpenSSLと、自分でビルドしたりアプリに同梱されていたりするOpenSSLとで、影響がまったく違うからです。

この記事では、OpenSSL 3.0の終了で何が変わったのかと、Linuxサーバーやコンテナを扱うインフラエンジニアがいま確認しておきたいことを順番に見ていきます。

OpenSSL 3.0のサポート終了とは？¶

OpenSSL 3.0は、2021年9月7日にリリースされた長期サポート（LTS）版です。

OpenSSLのLTSは5年間の公開サポートを受けられる決まりになっていて、3.0はちょうど5年後の2026年9月7日にその期間を終えました。公式ブログでも9月16日付けで終了が告知されています。

公開サポートの終了：OpenSSLプロジェクトが、そのバージョン向けのセキュリティ修正を誰でも入手できる形で出すのをやめること。ソフトウェアが動かなくなるわけではない。

ここで押さえておきたいのは、サポートが終わってもOpenSSL 3.0自体は普通に動き続けるという点です。

困るのは、この先に見つかる脆弱性です。終了後、3.0向けの修正はOpenSSLの有償サポート（プレミアムサポート）の契約者にしか提供されません。

実際に、終了から間もない9月末に深刻度Highの脆弱性修正が出た際、3.0向けの修正は有償の顧客向けだけだったと報じられています。

各バージョンのサポート期限¶

いまサポートされているバージョンを表にまとめておきます。日付はOpenSSLのリリース方針と各種のEOL情報サイトをもとにしています。

表を見ると分かるように、通常版のサポートは1年ちょっとしかありません。

サーバーで長く使うなら、選択肢は実質的にLTSの3.5になります。OpenSSLは今後も2年ごと（次は2027年4月）にLTSを出す方針を公表しています。

同じ9月に起きたFIPS 140-2の区切り¶

もうひとつ、暗号まわりで9月に区切りがありました。

アメリカの暗号モジュール認証制度（CMVP）で、FIPS 140-2の認証がすべて2026年9月21日に「Historical（過去のもの）」の扱いに移りました。既存のシステムで使い続けることはできますが、米国政府向けの新しい調達には使えなくなります。

国内のシステムで直接関係することは少ないと思います。ただ、海外の公共案件や、FIPSモードでOSを動かしている環境を触っているなら、OpenSSLのバージョン更新とあわせて確認しておくとよいでしょう。

OSに入っているOpenSSLはどうなる？¶

ここが一番誤解されやすいところです。

UbuntuやRHELのようなディストリビューションは、OpenSSLをそのまま配っているわけではありません。リリース時点のバージョンを固定して、その上に自分たちでセキュリティ修正を当て続けています（バックポートと呼ばれます）。

つまり、OSのパッケージとして入っているOpenSSLは、本家のサポートが終わってもOSのサポート期間中は修正が届き続けることが多いのです。

主なディストリビューションの状況¶

主なディストリビューションが標準で使っているOpenSSLのバージョンを整理すると、次のようになります。

RHELは、マイナーバージョンの更新のタイミングでOpenSSLを丸ごと新しい系列に入れ替えてきました。一方、UbuntuやDebian 12は3.0系を据え置いたまま、修正だけを取り込んでいます。

どちらのやり方でも、OSのサポートが続いていてパッケージを更新していれば、すぐに困ることはありません。

逆に言えば、注意が必要なのは次のようなケースです。

• OS自体のサポートがすでに切れている、または近い
• OSの更新を長いあいだ止めている
• OSのパッケージではないOpenSSLを使っている

最後の「OSのパッケージではないOpenSSL」が、今回いちばん見落としやすいところです。

確認しておきたいOpenSSLの置き場所¶

OpenSSLは、OSの中に1つだけあるとは限りません。

アプリが自分専用のOpenSSLを抱えていたり、コンテナイメージの中に別のバージョンが入っていたりします。ここでは、確認したい場所を順番に見ていきます。

OSのパッケージを確認する¶

まずはOS側です。openssl コマンドのバージョンと、ライブラリのパッケージのバージョンを見ておきます。

# コマンドのバージョン
openssl version

# Ubuntu / Debian
dpkg -l | grep -E 'libssl|openssl'

# RHEL / Rocky Linux / AlmaLinux
rpm -q openssl openssl-libs

UbuntuやDebianでは、openssl version が 3.0.2 のように古く見えても、パッケージのバージョン末尾（3.0.2-0ubuntu1.xx の部分）で修正が積み上がっています。

数字だけを見て「古いから危ない」と判断しないように気をつけてください。修正が届いているかどうかは、パッケージの更新履歴やディストリビューションのセキュリティ情報で確認するのが確実です。

アプリが同梱しているOpenSSLを確認する¶

次に、ミドルウェアや言語ランタイムがどのOpenSSLを使っているかを見ます。

# Nginxがリンクしているライブラリ
ldd $(which nginx) | grep -E 'libssl|libcrypto'

# Nginxのビルド時のOpenSSL
nginx -V 2>&1 | grep -i openssl

# Pythonが使っているOpenSSL
python3 -c "import ssl; print(ssl.OPENSSL_VERSION)"

# Node.jsが同梱しているOpenSSL
node -p process.versions.openssl

ldd の結果が /usr/lib の下のライブラリを指していれば、OSのOpenSSLを使っています。この場合はOSの更新で一緒に直ります。

注意したいのは、/opt や /usr/local の下を指している場合や、Node.jsのようにOpenSSLを中に組み込んでいる場合です。こうしたものはOSを更新しても直らないので、アプリ側のバージョンアップが必要になります。

ソースから自分でビルドしたNginxやApacheも同じです。ビルドしたときのOpenSSLがずっと使われ続けるので、どこかで作り直す必要があります。

コンテナイメージの中も見ておく¶

コンテナを使っている場合は、ホストのOpenSSLを更新しても、コンテナの中のOpenSSLは変わりません。

# イメージの中のOpenSSLを確認する
docker run --rm --entrypoint openssl myapp:latest version

# パッケージとして確認する（Debian系のイメージの場合）
docker run --rm --entrypoint dpkg myapp:latest -l | grep libssl

イメージによっては openssl コマンドが入っていないこともあります。その場合は、SBOM（ソフトウェア部品表）を出力できるツールや、イメージの脆弱性スキャナーで中身を確認するのが現実的です。

古いベースイメージのまま何年も作り直していないイメージは、意外と多いものです。この機会に、ベースイメージの更新とイメージの再ビルドが定期的に回っているかも確かめておくとよいでしょう。

移行するときに気をつけたいこと¶

OS外のOpenSSLを使っていて、3.5系へ上げることになった場合の注意点も触れておきます。

3.0から3.5は同じ3系なので、APIの大きな互換性は保たれています。ただ、まったく影響がないわけではありません。

実際に、RHEL 9.5でOpenSSLが3.2系に入れ替わったときには、一部のミドルウェアで動作の不具合が報告されています。RHEL 9.7でもFIPSモードのサーバーでTLSの接続に影響が出た事例がRed Hatのナレッジに載っています。

なので、いきなり本番を入れ替えるのではなく、検証環境で接続テストをしてから進めるのが安全です。特に、古い機器や古いクライアントと通信しているシステムは念入りに確認してください。

また、3.5にはML-KEMなどの耐量子暗号のアルゴリズムが入っています。将来の暗号の入れ替えに備える意味でも、LTSの3.5に寄せておく価値はあります。耐量子暗号については 耐量子暗号（PQC）とは？ で詳しく解説しています。

インフラエンジニアがいまやっておきたいこと¶

ここまでの話を、やることの順番に並べ直しておきます。

1. 持っているOpenSSLを洗い出す¶

まずは、どのサーバー、どのアプリ、どのコンテナに、どのOpenSSLが入っているかを把握することです。

台数が多い環境なら、構成管理ツールや脆弱性スキャナーの結果から一覧を作るのが早いでしょう。OSのパッケージなのか、アプリの同梱なのかを分けて記録しておくと、そのあとの判断がしやすくなります。

2. OSのサポート期限と照らし合わせる¶

OSのパッケージとして入っているなら、見るべきはOpenSSLではなくOSのサポート期限です。

たとえば、Ubuntu 22.04の標準サポートは2027年までです。その時期に合わせてOSを移行する計画があれば、OpenSSLもそこで一緒に新しくなります。サーバーOSの選び方とサポート期限の考え方は、2026年のLinuxディストリビューション選び にまとめています。

3. OS外のOpenSSLは個別にバージョンアップを計画する¶

アプリ同梱や自前ビルドのOpenSSLは、OSの更新では直りません。

ベンダー製品であれば、OpenSSL 3.0の終了への対応方針がサポート窓口やリリースノートで案内されていることが多いので、確認しておきましょう。

証明書の有効期間が短くなっていく流れも含めて、TLSまわりの運用はここ数年で大きく変わっています。あわせて 証明書の有効期間200日ルールと自動化 も読んでおくと、全体像がつかみやすいと思います。

まとめ¶

OpenSSL 3.0は、2026年9月7日に公開サポートを終了しました。この先に見つかる脆弱性の修正は、本家からは有償サポートの契約者にしか提供されません。

ただし、UbuntuやDebian、RHELなどのOSパッケージとして入っているOpenSSLは、OSのサポートが続く限りディストリビューションが修正を届けてくれます。慌てて入れ替えるより、OSの更新がきちんと回っているかを確認するほうが先です。

本当に気をつけたいのは、アプリに同梱されたOpenSSLや、自分でビルドしたもの、古いコンテナイメージの中に残っているOpenSSLです。これらはOSを更新しても直らないので、一度洗い出しておきましょう。

ライブラリがどこにあって、どのパッケージに属しているかを調べる力は、Linuxを扱ううえでの基本になります。パッケージ管理やライブラリの仕組みを体系的に学び直したい方は、InfraAcademyの Linuxロードマップ も活用してみてください。

TLSのエラー対応で困ったときは、curlのSSL証明書エラーの対処方法 も参考になるはずです。

サポート終了は、自分の環境の中身を見直すよいきっかけです。この機会に、足元のOpenSSLを一度確かめてみてください。

参考¶

• OpenSSL 3.0 End of Life（OpenSSL Library）
• OpenSSL 3.5 will be the next long term stable (LTS) release（OpenSSL Library）
• OpenSSL（endoflife.date）
• OpenSSL 3.0 Is End of Life. Its First High-Severity Fix Is for Paying Customers Only.（CertGuard）
• FIPS 140-2 sunsets in September 2026（OpenSSL Corporation）
• The experience of bringing OpenSSL 3.0 into Red Hat Enterprise Linux and Fedora（Red Hat）
• IMPALA-13592: OpenSSL rebase to 3.2 in RHEL / Rocky 9.5 breaks Impala（Apache Software Foundation Jira）
• Postfix on FIPS RHEL servers can no longer perform TLS handshakes after upgrade to RHEL 9.7（Red Hat Customer Portal）