OpenSSL 4.0は導入すべきか｜非LTSの落とし穴とEOL一覧・3.5 LTSとの選び方【2026年7月版】

OpenSSL 4.0.0は2026年4月14日にリリースされ、2026年6月9日にはセキュリティ修正版の4.0.1が出ています。3.0登場から約4年半ぶりのメジャー更新で、ENGINE APIの全廃とEncrypted Client Hello対応が目玉です。ただし4.0はLTSではなく、サポートは2027年5月14日で切れます。一方で3.5 LTSは2030年4月8日まで維持されます。「新しいから上げる」で決めると1年後にもう一度移行することになります。本記事では公式のリリース情報とサポート表を根拠に、EOL一覧・非互換の中身・バージョン確認手順・4.0と3.5 LTSの選び分けを整理します。

まとめ

• 最新版は4.0.1（2026年6月9日）。初版の4.0.0（2026年4月14日）には深刻度Highの脆弱性と2件のリグレッションが残っているため、4.0を使うなら4.0.1以上を選ぶ。
• 4.0は非LTS。サポートは2027年5月14日まで。長期運用が前提のサーバーは、2030年4月8日までサポートされる3.5 LTSが基本線になる。
• 3.0 LTSは2026年9月7日で終了。3.0で止まっている環境は、移行先を4.0ではなく3.5 LTSに置くほうが再移行を避けられる。
• 4.0の非互換の核はENGINE APIの全削除。engine.h依存のコードとサードパーティ製HSM/暗号モジュールはProviderへ書き換えないとビルドが通らない。
• 次のLTSは4.2（2027年4月予定・サポートは2032年4月まで）。ECHや耐量子アルゴリズムが今すぐ必要でないなら、3.5 LTSで待って4.2へ乗るのが移行回数を最小化する。

OpenSSL 4.0のリリース状況と最新バージョン

OpenSSL 4.0.0は2026年4月14日に正式リリースされました。公式リリースノートは「OpenSSL 4.0.0 is a feature release adding significant new functionality to OpenSSL」と位置づけており、機能追加とレガシー削除を同時に行ったメジャー更新です。2026年7月時点で入手すべき最新版は、その後に出た4.0.1です。

4.0.0を避けて4.0.1を選ぶべき理由

4.0.1は2026年6月9日公開のセキュリティパッチリリースで、リリースノートは「The most severe CVE fixed in this release is High」と明記しています。修正された脆弱性は計18件（うち深刻度High 1件）で、PKCS7_verify()のheap use-after-free（CVE-2026-45447）、CMS AuthEnvelopedDataでの偽造メッセージ受理（CVE-2026-34182）、QUICのPATH_CHALLENGEハンドラでのメモリ枯渇（CVE-2026-34183）、OCSPステープル応答チェックでのdouble free（CVE-2026-35188）などが並びます。

さらに4.0.1には、4.0.0で新規に入り込んだリグレッションの修正が2件含まれます。パスワードを対話入力で与えて秘密鍵を暗号化したときに openssl pkey がクラッシュする不具合と、openssl s_client -adv が16384バイトを一度に読み込むとセッションを早期終了する不具合です。メジャー版の初版は実運用で踏まれて初めて出る不具合を抱えます。4.0系を採用するなら4.0.0は飛ばし、4.0.1以降を起点にしてください。脆弱性が公表された際の影響範囲の切り分け方はCVE-2026-31431「Copy Fail」の対応手順で扱った手順がそのまま使えます。

4.1・4.2 LTS・5.0のリリース計画

OpenSSLは3.5以降、リリース戦略を「LTSは最低5年サポートし、少なくとも2年ごとに新しいLTSを指定する。非LTSは最低13か月サポートする」と定めています。加えて「2027年10月の5.0以降、メジャーリリースは隔年」となります。公表されている予定は次のとおりです。

読み取るべきは、4系で長期サポートを受けられるのは4.2だけという点です。4.0と4.1はどちらも13か月級の寿命しかありません。

OpenSSLのEOL・EOS（サポート終了）一覧とLTS区分

公式のリリース戦略ページが掲げるサポート終了日（EOL／EOS）は次のとおりです。バージョン番号の新しさとサポート期間の長さは一致しません。

3.0 LTSのEOL：2026年9月7日でアップストリーム修正が停止

いま実務で最も期限が近いのは4.0の話ではなく、3.0 LTSの終了です。3.0はUbuntu 22.04 LTSやRHEL 9世代のベースに広く入っており、2026年9月7日を過ぎるとアップストリームからのセキュリティ修正が止まります。ディストリビューションのバックポート提供が続く環境（Ubuntu ProやRHELのサブスクリプション等）はその範囲で保護されますが、自前でソースビルドしたOpenSSL 3.0を積んでいる場合は9月以降、修正が降ってきません。この移行先を4.0に取ると2027年5月にもう一度期限が来るため、3.5 LTSへ寄せるのが移行回数の面で有利です。

「非LTSの13か月」が運用に効く場面

非LTSの13か月は、四半期ごとの計画とリリース凍結期間を差し引くと、実質的に評価・検証・展開を1サイクル回せるかどうかの長さです。証明書更新やTLS設定の変更と重なると、期限内に次の版へ移りきれずEOLを跨ぐ状態になりがちです。4.0を選ぶなら、導入時点で「2027年5月14日までに4.2 LTSへ再移行する」ことを計画に書き込んでおく必要があります。

使用中のOpenSSLバージョンを確認する手順

移行判断の前に、いま何が動いているかを確定させます。コマンド版と、アプリケーションが実際にリンクしているライブラリ版は一致しないことがあるため、両方を見ます。

$ openssl version -a
OpenSSL 3.5.5 27 Jan 2026 (Library: OpenSSL 3.5.5 27 Jan 2026)
...
OPENSSLDIR: "/usr/lib/ssl"
ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-3"
MODULESDIR: "/usr/lib/x86_64-linux-gnu/ossl-modules"

openssl version -a の出力にある Library: の値が、そのコマンドが実行時にロードしている共有ライブラリの版です。コマンド本体と食い違う場合、複数のOpenSSLが同居しています。アプリケーション側が掴んでいる実体は次で確認します。

$ ldd $(which openssl) | grep -E 'libssl|libcrypto'
        libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3
        libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3

4.0ではsoname（共有ライブラリのバージョン識別子）がバンプされ、ソースツリーの VERSION.dat は SHLIB_VERSION=4 を持ちます。つまり4系は libssl.so.4 / libcrypto.so.4 となり、3系の libssl.so.3 とはファイル名の時点で別物です。両者はリンク時に取り違えられないため、3系を残したまま4.0を評価用に併設できます（インストール先は /usr/local など別プレフィックスに分けます）。リンク先が意図と違うときは LD_LIBRARY_PATH や rpath の設定を疑ってください。

サーバープロセスが掴んでいる版は、コマンド版と別に確認します。Nginxなら nginx -V、Apacheなら httpd -V の出力にビルド時のOpenSSL版が出ます。Pythonは python3 -c "import ssl; print(ssl.OPENSSL_VERSION)" で実行時にリンクしている版が取れます。TLSのバージョンと暗号スイートまで含めて棚卸しするなら、TLSとSSLの違い・バージョン選定の解説を併せて確認すると設定側の齟齬を見つけやすくなります。

OpenSSL 4.0で削除・変更されたAPIと互換性の壁

4.0は「機能追加より削除のほうが移行コストを生む」タイプのメジャー更新です。3.x向けに書かれたコードは、無変更ではコンパイルが通らない可能性があります。

ENGINE APIの全削除とProviderへの移行

公式NEWSは「Removed support for engines. The no-engine build option and the OPENSSL_NO_ENGINE macro are always present.」と記載しています。engine.h由来のシンボルは残っておらず、ENGINE_load_private_key() などを呼ぶコードはリンクエラーになります。代替はProvider frameworkで、鍵の取得は OSSL_PROVIDER_load() と OSSL_STORE 経由に置き換えます。

影響が大きいのは自社コードよりもサードパーティです。HSM、スマートカード、TPMを扱う商用モジュールがENGINE形式でしか提供されていない場合、ベンダーがProvider版を出すまで4.0では動きません。移行前に、3.x環境で no-engine を付けてビルドし直すと、4.0で壊れる箇所を先に洗い出せます。

ビルド時に露見する非互換

ENGINE以外にも、4.0の変更はコンパイル時に表面化します。公式NEWSで挙がっている主な項目は次のとおりです。

証明書検証も厳しくなりました。X509_V_FLAG_X509_STRICT を有効にしている環境ではAKID（Authority Key Identifier）の検証が追加され、CRL検証にも追加チェックが入ります。3.xで通っていた証明書チェーンが4.0で弾かれる可能性があるため、STRICTを使っているならステージングで実際の証明書を通して確認してください。また X509_cmp_time() 系は非推奨となり、X509_check_certificate_times() が推奨されます。

ECHと耐量子暗号：4.0の新機能が効く場面

4.0の目玉はEncrypted Client Hello（ECH）です。RFC 9849として2026年3月に標準化された仕様で、TLSハンドシェイクの最初のClient Helloを暗号化し、これまで平文で流れていたSNI（接続先ホスト名）を秘匿します。ドメイン単位のブロッキングやトラフィック分析に対して、接続先を隠せる点が実務上の違いです。ただしECHは配布側にHTTPS RRレコードでの公開鍵配布が必要で、サーバーにOpenSSL 4.0を入れれば自動的に有効になるものではありません。

耐量子側では、ML-DSA向けのML-DSA-MUダイジェストアルゴリズムに対応しました。加えてRFC 8998に沿った署名アルゴリズム sm2sig_sm3、鍵交換グループ curveSM2、耐量子ハイブリッドグループ curveSM2MLKEM768 が追加されています（TLS設定の -groups に書くのはこの名前です）。暗号プリミティブではSP 800-185準拠のcSHAKE、SNMPおよびSRTP向けのKDFが入りました。SM2/SM3は中国の商用暗号規格に準拠する必要がある案件で意味を持ちますが、国内の一般的なWebサービスで即座に必要になる機能ではありません。

整理すると、4.0の新機能が今すぐ効くのは「ECHを自社サービスで提供したい」「中国向け規格対応が要件にある」「PQC移行の検証を先行させたい」ケースに限られます。それ以外では、新機能は移行の動機になりません。

4.0へ上げるべき組織と、3.5 LTSで待つべき組織

結論から言えば、一般的な本番サーバーは今4.0に上げるべきではありません。理由は新機能の不足ではなく、寿命の短さです。4.0のサポートは2027年5月14日で切れます。移行の検証・展開に数か月かけ、安定した頃には次の移行計画を立てる時期になります。同じ工数を払うなら、2030年4月8日まで持つ3.5 LTSに寄せたほうが単位工数あたりの寿命が5倍以上長くなります。

この判断は、ディストリビューション側の選択とも一致します。Ubuntu 26.04 LTSは2026年4月23日リリースで、OpenSSL 4.0.0の公開（4月14日）に間に合う日程でしたが、採用したのは3.5.5です。5年サポートを約束する製品が、直前に出たメジャー版ではなくLTS系列を選んだという事実は、そのまま企業サーバーの判断基準になります。

逆に4.0を選ぶ合理性があるのは次の場合です。ECHやPQCの検証環境、寿命が数か月のコンテナイメージ、ENGINEを一切使っておらず依存も薄い新規プロジェクト、そして4.2 LTS（2027年4月予定）への移行を前倒しで検証したい開発チーム。いずれも「1年後に作り直す前提が成立する」環境です。長期運用が前提のシステムで4.0を選ぶのは、移行を2回払う選択になります。

ディストリビューションのOpenSSL 4.0採用状況

2026年7月時点で、主要ディストリビューションはまだ4.0へ動いていません。

Ubuntu 26.04 LTSはリリース時点で openssl 3.5.5-1ubuntu3 を収録し、2026年6月9日のセキュリティ更新で 3.5.5-1ubuntu3.2 が配布されています。Ubuntu 26.04 LTS（Resolute Raccoon）の全体像や、26.04の言語バージョン・x86-64-v3・サポート期間の詳細と併せて見ると、26.04は保守的なライブラリ選択で固めた版であることが分かります。Debianも安定版のtrixieが3.5.6、開発版のsidですら3.6.3で、4.0.1が入っているのはexperimentalだけです。

Fedoraは45で4.0を取り込む方針をChangeとして採択しており（提案者はRed HatのDmitry Belyavskiy氏、2026年7月2日更新時点でChangeAcceptedF45）、ENGINEや非推奨APIに依存するパッケージを救済するためのopenssl3互換パッケージの維持が論点になっています。Fedoraが先行して踏む形になるため、4.0の実運用上の落とし穴はまずFedora 45で表面化します。RHELなど他のディストリビューションは採用時期を公表していないため、自環境の予定は各ベンダーの公式情報で確認してください。

よくある質問

OpenSSL 4.0はLTSですか？

いいえ。4.0は非LTSで、サポートは2027年5月14日までです。4系で最初のLTSは2027年4月予定の4.2で、そちらは2032年4月までサポートされます。長期サポートが必要なら現時点では3.5 LTS（2030年4月8日まで）が選択肢になります。

OpenSSLの最新バージョンは何ですか？

2026年7月時点の最新は4.0.1（2026年6月9日公開）です。3系では3.6.3、3.5.7、3.4.6、3.0.21が同日に出ています。4.0.0には深刻度Highの脆弱性とリグレッションが残っているため、4.0系を使うなら4.0.1以降を選んでください。

OpenSSL 4.0のEOS（サポート終了）はいつですか？

2027年5月14日です。4.0は非LTSのため、公式のリリース戦略が定める「非LTSは最低13か月」の枠に収まります。同じく非LTSの4.1は2027年11月、次のLTSである4.2は2032年4月がサポート終了予定です。

OpenSSL 3.0のEOLはいつですか？

3.0 LTSは2026年9月7日にサポート終了します。ディストリビューションがバックポート提供を続ける場合はその範囲で保護されますが、自前ビルドの3.0を使っている環境はアップストリームの修正が止まります。移行先は、再移行を避ける観点から3.5 LTSが有力です。

ENGINEを使っているコードは4.0で動きますか？

動きません。4.0はENGINE APIを完全に削除しており、engine.h由来のシンボルは残っていません。Provider frameworkへの書き換えが必要です。HSMなどのサードパーティモジュールがENGINE形式でしか提供されていない場合は、ベンダーのProvider対応版が出るまで4.0へ移行できません。

使用中のOpenSSLバージョンはどう確認しますか？

openssl version -a を実行し、先頭の版と Library: の値の両方を確認します。両者が食い違う場合は複数のOpenSSLが同居しています。アプリケーションが実際にリンクしているライブラリは ldd でlibssl・libcryptoの解決先を追って特定してください。

関連記事

• TLSとは？SSLとの違い・仕組みとバージョン選定を実装者向けに解説【2026年最新】
• Ubuntu 26.04 LTS（Resolute Raccoon）とは｜リリース日・新機能・24.04からのアップグレード
• Ubuntu 26.04 LTS 開発者向け詳細｜言語バージョン・x86-64-v3・フレーバー・サポート期間
• CVE-2026-31431「Copy Fail」とは？影響範囲と今すぐ行うべきパッチ・緩和策をわかりやすく解説