OpenSSL 4.0は非LTS｜最新4.0.3・EOL一覧と3.5 LTSの選び方【2026年10月】

OpenSSL 4.0の最新版は、2026年9月29日に公開された4.0.3です。4.0はLTSではなく、サポートは2027年5月14日で終わります。同じ時期に3.4は2026年10月22日、3.6は2026年11月1日にサポートを終え、3.0 LTSは2026年9月7日にすでに終了しました。この記事では、版ごとのEOL一覧と、使用中の版の確認手順、4.0で壊れるコードと新機能のECHを、OpenSSL 4.0.3と3.6系をローカルで動かした結果を交えて整理し、4.0に上げるか3.5 LTSで待つかを判断できるようにします。

まとめ

• 4.0系の最新は4.0.3（2026年9月29日）。4.0.0公開後の3回の修正で計43件のCVEが直っているため、4.0を使うなら4.0.3以上にする。
• 4.0は非LTSで2027年5月14日まで。長く運用するサーバーは、2030年4月8日までサポートされる3.5 LTSが基本線になる。
• 3.4は2026年10月22日、3.6は11月1日に終了。3.0は9月7日に終わり、以後の修正版3.0.23は有償契約者にしか提供されない。
• 次は4.1（2026年10月予定・非LTS）、次のLTSは4.2（2027年4月予定）。4.1.0-beta2は10月9日に出ており、DTLS 1.3に対応する。
• 4.0の非互換の核はENGINEの削除。ENGINEを呼ぶコードは警告つきでコンパイルが通り、リンクで落ちる。スタブで逃がすとENGINEの読み込みがNULLを返すだけになる。
• 耐量子の鍵交換は4.0に上げる理由にならない。X25519MLKEM768は3.6系でも既定で使われる。4.0でしか得られない機能はECHが中心。

OpenSSL 4.0の最新バージョン4.0.3と修正内容

OpenSSL 4.0.0は2026年4月14日に公開されました。公式のリリース告知は「OpenSSL 4.0 is not a long term stable (LTS) release」と明記し、サポート期限を2027年5月14日としています。その後、4.0系にはセキュリティ修正版が3回出ました。各版の内容は4.0.3タグのNEWS.mdにまとまっています。

4.0.1〜4.0.3で直った脆弱性とリグレッション

4.0.0のまま動かしている環境には、この43件の修正が入っていません。実際に影響を受けるかは、DTLSやQUIC、CMSなど使っている機能によって変わります。4.0.1には、4.0.0で入り込んだ不具合の修正も2件あります。パスワードを対話入力して秘密鍵を暗号化すると openssl pkey がクラッシュする不具合と、openssl s_client -adv が16384バイトを一度に読むとセッションを早期終了する不具合です。

4.0.3で直ったHighのCVE-2026-84782は、DTLSで分割送信中の書き込みが止まっている間に再送タイマーが動くと、ヒープの内容を相手に送るかクラッシュする問題です。2026年9月29日のセキュリティアドバイザリによれば影響はDTLSを使う構成に限られ、TLSだけのWebサーバーには該当しません。ただし同じ回の14件には、TLSサーバーに関係するLowの修正（ハンドシェイク中に SSL_set_SSL_CTX() を呼んだ後の範囲外アクセス）も含まれるため、DTLSを使っていなくても4.0.3へ上げる理由はあります。

4.1.0は2026年10月公開予定：beta2の変更点

次の4.1は2026年10月公開の予定で、2026年9月9日にalpha1、9月23日にbeta1、10月9日にbeta2が出ています。4.1ベータの告知に並ぶ新機能は次のとおりです。

• DTLS 1.3（RFC 9147）への対応と、SSLリスナーAPIでのDTLS対応
• RFC 8701のGREASE（未知の拡張値を混ぜて相手実装の硬直を防ぐ仕組み）への対応
• IKEv2 KDFへの対応、x86_64でのML-DSA・AES-CBC復号の最適化
• tsget が使うPerlモジュールを Net::Curl::Easy へ変更、no-ecdsa・no-ecdh のビルドオプションを削除

4.1は4.0と同じメジャー版なのでAPI・ABIの互換が保たれ、4.0で動くコードは原則そのまま動きます。一方で4.1も非LTSで、公式ロードマップのサポート期限は2027年11月です。4.0から4.1へ移っても延びるのは半年ほどで、長期運用の問題は解決しません。

OpenSSLのバージョン一覧とEOL（サポート終了日）

リリース戦略では、3.5以降のLTSは少なくとも5年、非LTSは13か月サポートされます。リリースは毎年4月と10月の2回で、LTSは奇数年の4月に出ます。2026年10月15日時点のダウンロードページとロードマップを合わせた一覧が次の表です。

番号が大きいほど長く使えるわけではありません。2026年10月時点で最も長く修正を受けられるのは3.5（2030年4月8日まで）で、4.0より約3年長く続きます。

3.4は10月22日、3.6は11月1日に終了

いま期限が迫っているのは4.0ではなく3.4と3.6です。どちらも最後の公開版は2026年9月29日の3.4.8と3.6.5で、終了日以降に見つかった脆弱性は公開版では直りません。3.6は2025年10月公開の非LTSで、旧方針の「非LTSは2年」ではなく新方針の13か月が適用されたため、3.4より後に出たのに終了はわずか10日後です。3.6から移るなら、3.6固有のAPIや機能に依存していないことを確かめたうえで、3.5 LTSへ戻して3.5のヘッダとライブラリで再ビルドするのが、手戻りの少ない選択です。

3.0 LTSは2026年9月7日に終了：3.0.23は有償契約者のみ

3.0のEOL告知のとおり、3.0は2026年9月7日で公開のセキュリティ修正が止まりました。9月29日のアドバイザリでは、3.0の修正版3.0.23が「Premium support customers only」と明記されています。自前ビルドの3.0を使い続ける環境は、同じ日に直った3.5.9相当の修正を受け取れません。

FIPSを要件にしている場合は別の期限もあります。同じ告知によると、3.0のFIPSプロバイダーに残るFIPS 140-2の認証は2026年9月21日にCMVPのHistorical Listへ移りました。ダウンロードページの検証済み一覧は2026年10月15日時点でも3.1.2（FIPS 140-3）と3.0系の3本だけで、4.0のFIPSプロバイダーは載っていません。FIPS要件のある環境で4.0を採用する前に、使うプロバイダーの認証状況を確認してください。

4.2 LTSと5.0の予定

2026年5月7日のリリース計画の更新で、メジャー版は2年ごとと決まりました。2027年4月に4.2（LTS）、2027年10月に5.0（非LTS）が出る予定です。告知には「the final 4.x release will be supported for the entire 5.x release cycle」とあり、4系の最後のLTSである4.2が5系の期間を通して支えられます。3.5から次に移る先は4.0や4.1ではなく、4.2 LTSと考えるのが自然です。

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

移行を判断する前に、実際に動いている版を確定させます。コマンドの版と、アプリケーションが読み込むライブラリの版は一致しないことがあるため、両方を確認します。次はmacOS（Homebrewの openssl@4）で実行した出力です。

$ openssl version -a
OpenSSL 4.0.3 29 Sep 2026 (Library: OpenSSL 4.0.3 29 Sep 2026)
built on: Tue Sep 29 13:44:55 2026 UTC
platform: darwin64-x86_64-cc
OPENSSLDIR: "/usr/local/etc/openssl@4"
MODULESDIR: "/usr/local/Cellar/openssl@4/4.0.3/lib/ossl-modules"

先頭の版がコマンド本体、Library: の値が実行時に読み込んでいる共有ライブラリの版です。両者が食い違う場合は、複数のOpenSSLが同居しています。4.0はsonameが4に上がったため、Linuxでは libssl.so.4 と libcrypto.so.4 になり、3系の libssl.so.3 とはファイル名から別物です。Fedora 45のコンテナで確かめると次のようになります。

$ ldd $(command -v openssl) | grep -E 'libssl|libcrypto'
	libssl.so.4 => /lib64/libssl.so.4
	libcrypto.so.4 => /lib64/libcrypto.so.4

サーバープロセスが使う版はコマンドとは別に見ます。Nginxは nginx -V でビルド時の版が分かります。Apacheの httpd -V にはOpenSSLの版が出ないため、ldd で mod_ssl.so がリンクしている libssl を調べます。Pythonは python3 -c "import ssl; print(ssl.OPENSSL_VERSION)" で実行時の版が分かります。ライブラリを更新しても、起動中のプロセスは古いライブラリを読み込んだままなので、再起動するまで修正は効きません。TLSのバージョンと暗号スイートまで棚卸しするなら、TLSとSSLの違いとバージョン選定の確認手順も参考になります。

ディストリ版OpenSSLのバックポートと修正状況

Linuxディストリビューションの openssl version は、上流の最新版より古い番号を表示することがよくあります。ディストリは版番号を据え置いたまま、修正だけを取り込む（バックポートする）からです。Ubuntu 26.04 LTSのコンテナで確かめた結果が次です。

$ openssl version
OpenSSL 3.5.5 27 Jan 2026 (Library: OpenSSL 3.5.5 27 Jan 2026)
$ dpkg -l openssl | tail -1
ii  openssl  3.5.5-1ubuntu3.7  amd64  Secure Sockets Layer toolkit - cryptographic utility

表示は3.5.5のままですが、UbuntuのCVE-2026-84782のページでは、上流が3.5.9で直したこのHighの脆弱性が26.04向けに 3.5.5-1ubuntu3.6 で修正済みになっています。24.04 LTSの3.0.13と22.04 LTSの3.0.2も修正済みで、上流がEOLにした3.0でもUbuntuは修正を続けています。ディストリのパッケージを使っているなら、判定は openssl version の番号ではなく、パッケージの版とディストリのセキュリティ情報で行ってください。脆弱性スキャナが番号だけを見て「3.5.5は脆弱」と報告するのは典型的な誤検知です。逆に、上流のソースから自前でビルドしたOpenSSLは、自分でパッチを当てない限り番号のとおりの修正しか入っていません。コンテナも同じで、ベースイメージのディストリのパッケージか、自前ビルドかで判定の仕方が変わります。

OpenSSL 4.0で削除・変更されたAPIとビルド非互換

4.0は機能追加より削除が移行コストを生むメジャー更新です。ENGINE削除の告知のとおり、ENGINE関連のシンボルは共有ライブラリから消えました。

ENGINE呼び出しのコンパイル警告とリンクエラー

ENGINE_by_id() を1回呼ぶだけのCコードを、4.0.3と3.6系のヘッダ・ライブラリでそれぞれビルドしました。libcrypto が公開する ENGINE_ で始まるシンボルは、3.6系の121個に対して4.0.3では0個です。

#include <stdio.h>
#include <openssl/engine.h>
int main(void) {
    ENGINE *e = ENGINE_by_id("dynamic");
    printf("%p\n", (void *)e);
    return 0;
}

これを eng.c として保存し、macOSのHomebrew環境では P4="$(brew --prefix openssl@4)" と設定してからビルドします。

$ cc eng.c -I$P4/include -L$P4/lib -lcrypto -o eng
eng.c:4:17: warning: 'ENGINE_by_id' is deprecated [-Wdeprecated-declarations]
Undefined symbols for architecture x86_64:
  "_ENGINE_by_id", referenced from:
ld: symbol(s) not found for architecture x86_64

4.0.3の engine.h は削除されずに残っており、関数の宣言もあるため、コンパイルは非推奨の警告だけで通ります。失敗するのはリンクの段階です。ビルドログの警告を読み飛ばしていると、原因がENGINEだと気づきにくい点に注意が要ります。

このヘッダには OPENSSL_ENGINE_STUBS を定義するとリンクエラーを隠すスタブに切り替わる仕組みがあります。同じコードを cc -DOPENSSL_ENGINE_STUBS eng.c -I$P4/include -L$P4/lib -lcrypto -o eng でビルドすると成功し、実行すると ENGINE_by_id() は 0x0（NULL）を返しました。スタブはビルドを通すためだけのもので、ENGINEの機能は何も動きません。4.0.3の engine.h のスタブは、関数ごとに0かNULLを返すか、何もしないだけです。HSMの鍵をENGINE経由で読むコードをスタブで通すと、戻り値を確かめていない箇所から実行時に失敗します。スタブを使ってよいのは、ENGINEを読み込めなかったときにエラーとして扱うか、別の経路へ切り替えるなど、ENGINEが無くても正しく動くと確認できたコードに限ります。

代わりはProvider APIで、鍵の読み込みは OSSL_STORE と OSSL_PROVIDER_load() に置き換えます。影響が大きいのは自社コードより、ENGINE形式でしか提供されていないHSMやスマートカードのモジュールです。Nginxの ssl_engine ディレクティブもENGINEを前提にしています。Fedora 45は4.0を既定にしたうえで、3.5.9の openssl3-libs と openssl3-devel-engine を別パッケージで用意しており、ENGINEを使うソフトの逃げ道を残しています。クラウドのHSMをPKCS#11で使う構成は、AWS CloudHSMの構築手順のように、ベンダーがProviderやPKCS#11ライブラリを出しているかを先に確認してください。

ASN1_STRINGのopaque化などコンパイル時の非互換

ENGINE以外の非互換はコンパイル時に表に出ます。ASN1_STRING のメンバを直接読む s->length は、3.6系では通り、4.0.3ではincomplete definition of type 'ASN1_STRING'でエラーになりました。ASN1_STRING_length() などのアクセサ関数に置き換えれば、3系と4系の両方で通ります。NEWS.mdに載る主な変更と対応は次のとおりです。

証明書の検証も厳しくなりました。X509_V_FLAG_X509_STRICT を有効にしている環境ではAKID（Authority Key Identifier）の検証が加わり、CRLの検証にも追加のチェックが入ります。3.xで通っていた社内CAの証明書チェーンが4.0で弾かれることがあるため、ステージングで実際の証明書を通して確かめてください。

OpenSSL 4.0のECHとs_clientによる接続試験

4.0で加わった機能の中心は、Encrypted Client Hello（ECH、RFC 9849）です。TLSハンドシェイクの最初のClientHelloを暗号化し、これまで平文で流れていた接続先のホスト名（SNI）を隠します。暗号化されるのは内側のClientHelloにあるSNIなどで、外側のClientHelloには共用の名前だけが載ります。ただしRFC 9849が注意しているとおり、平文のDNS問い合わせや接続先のIPアドレスから相手が分かる場合は残るため、ECHだけで接続先を完全に隠せるわけではありません。上流の3.6系の s_client には -ech_config_list オプションも openssl ech コマンドもなく、上流のOpenSSLでECHが使えるのは4.0からです。

ECHの公開鍵（ECHConfigList）は、DNSのHTTPSレコードで配られます。OpenSSLにECHを実装したDEfOプロジェクトの試験サイト defo.ie のHTTPSレコードにある ech= の値（Base64形式のECHConfigList）を取り出して渡すと、4.0.3ではECHが成立しました。先に openssl version で4.0系が動いていることを確かめてください。取り出しにはDoHのJSON APIを使い、bashで実行しています。この例はECHの成立を見るためのもので、s_client は証明書の検証に失敗しても接続を続けます。接続先の認証まで確かめるなら -verify_return_error -verify_hostname defo.ie を足してください（2026年10月15日の試験では、付けた場合も Verify return code: 0 (ok) でECHが成立しました）。

$ openssl version
OpenSSL 4.0.3 29 Sep 2026 (Library: OpenSSL 4.0.3 29 Sep 2026)
$ ECH=$(curl -s -H 'accept: application/dns-json' \
    'https://cloudflare-dns.com/dns-query?name=defo.ie&type=HTTPS' \
    | grep -o 'ech=[^ "]*' | head -1 | cut -d= -f2-)
$ openssl s_client -connect defo.ie:443 -servername defo.ie \
    -ech_config_list "$ECH" -ign_eof
ECH: success: 1
ECH: inner: defo.ie
ECH: outer: cover.defo.ie

本当の接続先 defo.ie は暗号化された内側にあり、外側には cover.defo.ie だけが載っています。一方、同じ日に crypto.cloudflare.com がDNSで公開しているECHConfigListで試すと、TLSのalert 47（illegal_parameter）で切断され、ECH: tried but failed になりました。原因はこの試験の範囲では特定していません。ECHは、対応するクライアントとサーバー、有効なECHConfigListがそろって初めて効きます（今回はECHConfigListをDNSから取得しました）。相手によって結果が変わります。自社サービスで提供するなら、主要ブラウザとの相互接続を試験してから公開してください。DNSのHTTPSレコードの取得には、DNS over HTTPSの仕組みで解説しているDoHのJSON APIが使えます。

サーバー側の鍵は openssl ech で作れます。openssl ech -public_name ech.example.com -out echkey.pem を実行すると、X25519の秘密鍵と、DNSのHTTPSレコードに載せるECHCONFIGが1つのPEMファイルに出力されました。

OpenSSL 3.5以降の耐量子鍵交換と既定グループ

www.google.com へ既定設定で接続すると、4.0.3でも3.6系でも鍵交換は X25519MLKEM768 になりました。3.5のNEWS.mdには「The default TLS supported groups list has been changed to include and prefer hybrid PQC KEM groups」とあり、ML-KEMを使うハイブリッドの鍵交換は3.5から既定で優先されています。4.0で増えた耐量子関連は、中国の国家規格向けの curveSM2MLKEM768 グループと、ML-DSA向けの「ML-DSA-MU」ダイジェストなどに限られます。量子コンピュータへの備えを理由に4.0へ上げる必要はなく、3.5 LTSで同じ鍵交換が使えます。ハイブリッド方式の考え方はハイブリッド暗号方式とPQC移行で解説しています。

4.0へ上げる環境と、3.5 LTSで待つ環境

OpenSSLを自前でビルドして保守している本番サーバーで、ECHなど4.0固有の機能が要らないなら、2026年10月時点で4.0に上げるべきではありません。理由は機能ではなく寿命です。4.0のサポートは2027年5月14日で切れ、移行の検証と展開に数か月かければ、安定した頃にはまた次の移行計画が要ります。同じ工数を払うなら2030年4月8日まで修正が続く3.5 LTSに乗り、2027年4月公開予定の4.2 LTSへは、検証の時間を十分に取ってから移るほうが安全です。

この判断はディストリビューションの選択とも一致します。Ubuntu 26.04 LTSは4.0.0の公開から9日後の2026年4月23日に出ましたが、採用したのは3.5.5です。5年のサポートを約束する製品が、直前に出たメジャー版ではなくLTS系列を選んでいます。

4.0を選んでよいのは、次のように「1年以内に作り直す前提」が成り立つ環境です。

• ECHを自社サービスで提供したい、または検証を先行させたい
• RFC 8998（TLS 1.3でのSM2・SM3）への対応が要件にあり、署名アルゴリズム sm2sig_sm3 や鍵交換グループ curveSM2 を使う
• コンテナイメージを修正版ごとに再ビルドして配備でき、4.0のEOL前に次の系列へ移す計画がある（ENGINEにも古いAPIにも依存していない）
• 4.2 LTSへの移行を前倒しで検証したい開発チーム

避けるべき失敗は、3.0のEOLに追われて4.0へ飛び移ることです。3.0から4.0へ移ると、ENGINEの削除とAPIの非互換を一度に引き受けたうえで、2027年5月14日の4.0のEOLまでに、2027年4月公開予定の4.2へもう一度移ることになります。3.0から3.5なら同じ3系の中での移行で済み、2030年4月8日までのサポート期間を使って次の系列への移行を計画できます。社内の版がそろっているか不安な場合や、脆弱性対応の優先度を外部の目で確かめたい場合は、脆弱性診断・セキュリティ診断で使用中のライブラリの棚卸しから相談できます。

ディストリビューションのOpenSSL採用状況（2026年10月）

2026年10月15日時点で、各ディストリのパッケージ情報（Debianのソース一覧、Launchpad、FedoraのBodhi、Arch Linuxのパッケージ検索）を直接引いた結果です。次の表に掲載した環境で4.0を既定にしているのは、リリース前のFedora 45だけです。

Debianの開発版とArch Linuxは3.6系に乗っていて、3.6は2026年11月1日に終わります。3.6系を使っている環境は、ディストリが次にどの系列へ移るかを11月1日の前に確かめておく必要があります。Ubuntu 26.04 LTSの全体像はUbuntu 26.04 LTSのリリース内容とアップグレードにまとめています。

よくある質問

OpenSSL 4.0はLTSですか？

いいえ。4.0は非LTSで、サポートは2027年5月14日までです。4系で最初のLTSは2027年4月予定の4.2で、2032年4月までサポートされる予定です。いま長期サポートが必要なら、2030年4月8日まで続く3.5 LTSを選びます。

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

2026年10月15日時点の最新の正式版は、2026年9月29日公開の4.0.3です。同じ日に3.6.5、3.5.9、3.4.8も出ています。4.1は10月9日に4.1.0-beta2が出ており、2026年10月中に正式版が出る予定です。

OpenSSL 3.0のサポート期限（EOL）はいつですか？

2026年9月7日に終了しました。その後の修正版3.0.23は有償サポートの契約者にしか提供されていません。ディストリのパッケージを使っている場合はディストリの修正が続く範囲で保護されますが、自前でビルドした3.0には修正が届きません。移行先は3.5 LTSが有力です。

OpenSSL 3と4の違いは何ですか？

4.0ではENGINE API、SSLv3、c_rehashなどが削除され、ASN1_STRINGのopaque化やX509系APIへのconst追加でソースの修正が必要になることがあります。共有ライブラリも libssl.so.3 から libssl.so.4 に変わり、3系向けにビルドしたバイナリは再ビルドが必要です。新機能の中心はECHです。

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

動きません。4.0.3で試すと、ENGINEを呼ぶコードは非推奨の警告つきでコンパイルが通り、リンクで失敗しました。OPENSSL_ENGINE_STUBS でビルドを通しても、ENGINE_by_id() はNULLを返し、ほかのENGINE関数も0やNULLを返すか、何もしないだけです。Providerへの書き換えが必要です。

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

openssl version -a を実行し、先頭の版と Library: の値の両方を確認します。アプリケーションが読み込んでいるライブラリは ldd で libssl と libcrypto の解決先を見ます。ディストリのパッケージは番号を据え置いて修正を取り込むため、脆弱性の判定はパッケージの版で行います。

関連記事

• TLSとは？SSLとの違い・仕組みとバージョン選定を実装者向けに解説【2026年最新】
• TLS 1.3とは？RFC 8446の仕組みと0-RTTの採否を実装者向けに解説
• RSA暗号とは？仕組みと鍵長・パディングの選び方をOpenSSLの実装で解説
• Ubuntu 26.04 LTS（Resolute Raccoon）とは｜リリース日・新機能・24.04からのアップグレード
• ハイブリッド暗号方式とは？仕組みとPython実装・PQC移行を解説