FortiOS 7.6.7 の IKEv2 証明書認証失敗｜中間 CA の対処

はじめに

FortiGate を 7.6.7 へ更新した直後から、IKEv2 の IPsec VPN が接続できなくなる事象が Fortinet から公開されています。Bug ID 1304588 として管理されている既知不具合で、証明書認証を使用している構成が対象です。

やっかいなのは、同じ VPN 設定でも端末によって成否が分かれる点です。接続できる端末があるため、FortiGate 側ではなく特定の端末の問題に見えやすく、原因の切り分けに時間がかかります。SSL-VPN から IKEv2 IPsec VPN へ移行した環境では、移行作業そのものを疑ってしまう場面も想定されます。移行の背景は『FortiGate SSL-VPN 廃止と IPsec VPN（TCP/443）への移行手順』で扱っています。

結論として、FortiOS 7.6.7 では send-cert-chain が有効でも中間 CA 証明書が IKEv2 の証明書ペイロードに含まれない場合があり、必要な中間 CA を保持していない端末では、FortiGate 証明書を検証できず認証に失敗する可能性があります。Fortinet が示す回避策は、影響を受ける端末の信頼された中間証明機関ストアへ、必要な中間 CA 証明書を導入することです。修正は 7.6.8 と 8.0.1 で対応予定と Fortinet Community に記載されています。

FortiOS 7.6.7 の IKEv2 証明書認証失敗と Bug ID 1304588

本件は Fortinet Community の Troubleshooting Tip として 2026 年 8 月 5 日に公開され、FortiOS 7.6.7 の Release Notes にも IPsec VPN の Known Issues として掲載されています。CVE を伴う脆弱性情報ではなく、可用性に影響する製品不具合として整理します。

参考: Fortinet Community
“may fail to send the intermediate CA certificate in the IKEv2 certificate payload”
（IKEv2 の証明書ペイロードで中間 CA 証明書を送信できない場合があります。）
https://community.fortinet.com/fortigate-3/troubleshooting-tip-ikev2-certificate-authentication-fails-after-upgrading-to-fortios-v7-6-7-229273

発生条件と対象にならない構成

Fortinet が示す Scope は FortiGate、FortiOS 7.6.7、証明書ベースの認証です。自環境が該当するかどうかは、次の条件で判断します。

これらの条件が重なると、本不具合によって認証に失敗する可能性があります。FortiOS 7.6.7 のすべての IPsec VPN が接続できなくなるわけではなく、PSK 認証や証明書を使用しない構成は本不具合の対象外です。

典型的な症状

Fortinet が挙げている症状は次のとおりです。

• 7.6.7 へ更新する前は VPN が正常に動作していた
• IKE 認証の段階でトンネル確立が失敗する
• 7.6.6 へ戻すと接続が回復する
• 端末へ中間 CA 証明書を導入すると接続できるようになる

VPN の設定を変更していないのに更新後だけ失敗する、という点が判断材料になります。設定変更や証明書の有効期限切れとは切り分けて考える必要があります。

send-cert-chain が有効でも認証に失敗する理由

本不具合を理解するうえで重要なのは、send-cert-chain が無効だから失敗するのではない、という点です。この設定は既定で有効であり、有効なまま中間 CA が送信されないことが不具合の要点になります。

FortiOS の CLI Reference では、send-cert-chain は証明書チェーンの送信を有効・無効にする設定として定義され、既定値は enable です。したがって、この値を設定し直せば必ず復旧するというものではありません。

IKEv2 で使用する証明書チェーン

FortiGate のサーバー証明書

IKEv2 の相手へ FortiGate の識別情報を提示し、証明書ベースで認証するための証明書です。IKE_AUTH のやり取りで相手へ提示されます。

中間 CA 証明書

サーバー証明書に署名した下位 CA の証明書です。ルート CA とサーバー証明書をつなぐ役割を持ち、これが欠けるとチェーンが途切れます。

ルート CA 証明書

チェーンの起点となる自己署名証明書です。端末側では信頼されたルート証明機関のストアに置きます。中間 CA と役割が異なるため、同じストアへまとめて入れる運用は適切ではありません。

IKEv2 の証明書ペイロードと send-cert-chain

FortiGate が証明書チェーンを送信するかどうかを制御する Phase 1 の設定です。既定は enable ですが、7.6.7 では有効でも中間 CA がペイロードに含まれない場合があります。

Fortinet の管理ガイドは、ダイヤルアップ VPN の証明書認証について、ルート CA 証明書と、ユーザー証明書・サーバー証明書に署名した下位 CA の証明書の扱いを次のように説明しています。

参考: FortiOS Administration Guide
“must be imported into the FortiGate and client machines”
（FortiGate とクライアント端末の両方へインポートする必要があります。）
https://docs.fortinet.com/document/fortigate/8.0.0/administration-guide/443323/dialup-vpn-with-certificate-authentication

Fortinet の当該ダイヤルアップ VPN 構成例では、ルート CA と、ユーザー証明書やサーバー証明書へ署名した下位 CA の証明書を、FortiGate とクライアント端末へ導入する構成が示されています。一方、Bug ID 1304588 の問題は、send-cert-chain が有効でも FortiGate が中間 CA を送信しない点にあります。端末への中間 CA 導入は、Fortinet が提示している本不具合の回避策として整理します。

接続できる端末と失敗する端末の違い

同じ FortiGate、同じトンネル設定でも成否が分かれるのは、端末側が中間 CA 証明書を持っているかどうかが分岐点になるためです。

この表のうち、FortiGate が中間 CA を送信しない場合に端末が検証に失敗し得ることと、中間 CA を導入すると接続できるようになることは Fortinet が示した内容です。端末ごとに中間 CA の保持状況が異なる理由については、公式情報で個別に説明されていません。過去の証明書利用や端末管理基盤による配布など複数の要因が考えられますが、本記事では原因を断定しません。

一部の端末でのみ症状が出るため、FortiGate 側の不具合であっても端末固有の問題として扱われやすい点が、本件の切り分けを難しくしています。まずは失敗する端末と成功する端末の証明書ストアを比較することが近道です。

Bug ID 1304588 の影響確認と切り分け

ここでは本不具合への該当を判断するために必要な確認だけを扱います。IKE の詳細なデバッグや一般的な IPsec の設定確認は『FortiGate IPsec VPN の構築手順｜IKEv2 と NAT 越えの設定例』を参照してください。

FortiOS と Phase 1 設定を確認する

最初に、稼働中の FortiOS バージョンを確認します。

get system status

次に、対象トンネルが IKEv2 と証明書認証を使用しているかを確認します。show は既定値を表示しないため、show full-configuration を使うと ike-version や authmethod も含めて確認できます。

show full-configuration vpn ipsec phase1-interface <tunnel_name>

send-cert-chain の現在値だけを確認する場合は、Fortinet Community が示している次のコマンドを使用できます。

show full-configuration vpn ipsec phase1-interface <tunnel_name> | grep send-cert-chain

ここで enable が返ってきても、それは正常な設定です。設定を疑うのではなく、端末側の証明書ストアの確認へ進んでください。

端末の中間 CA 証明書を確認する

Windows 端末では、証明書ストアをローカル コンピューターと現在のユーザーの 2 種類に分けて管理します。Microsoft のドキュメントでは、MMC に証明書スナップインを追加して確認する手順が案内されています。

1. Win + R を押し、mmc と入力して実行する
2. ファイル、スナップインの追加と削除の順に開く
3. 証明書を選択して追加する
4. ローカル コンピューターを見る場合はコンピューター アカウント、現在のユーザーを見る場合は自分のユーザー アカウントを選ぶ
5. 中間証明機関のストアを開き、対象の中間 CA 証明書が存在するかを確認する

どちらのコンテキストを確認すべきかは、利用する VPN クライアントと証明書の利用コンテキストによって変わります。公式情報でどちらか一方に限定されているわけではないため、両方を確認するほうが確実です。なお Microsoft は、現在のユーザーのストアとローカル コンピューターのストアの関係を次のように説明しています。

参考: Microsoft Learn
“inherit the contents of the local machine certificate stores”
（ローカル コンピューターの証明書ストアの内容を継承します。）
https://learn.microsoft.com/en-us/windows-hardware/drivers/install/local-machine-and-current-user-certificate-stores

Microsoft の説明では、現在のユーザーの個人ストアを除く各ストアがローカル コンピューターのストアの内容を継承します。ローカル コンピューター側に中間 CA 証明書があれば、現在のユーザー側の中間証明機関ストアからも参照できることになります。

コマンドラインで確認する場合は certutil を使用できます。Microsoft のリファレンスでは、-store が証明書ストアをダンプする機能として定義され、ストア名の例として My、CA（既定）、Root が挙げられています。-user を付けるとマシンストアではなくユーザーストアを参照します。

certutil -store CA
certutil -user -store CA

Microsoft は certutil について、証明書の内容を確認するためのツールであり、運用コードでの使用は推奨しないと注記しています。確認用途にとどめ、変更操作は MMC のインポート ウィザードや正規の配布手段を使うほうが安全です。

FortiGate 側と端末側を切り分ける

FortiGate 側で確認すること

FortiOS が 7.6.7 か、対象トンネルが IKEv2 と証明書認証か、send-cert-chain が有効か。すべて満たしていれば、単純な設定ミスだけでなく、本不具合を優先的に疑う材料になります。

端末側で確認すること

必要な中間 CA 証明書が中間証明機関のストアにあるか。ルート CA が存在することをもって中間 CA も存在すると判断しないよう注意します。

比較して判断すること

接続できる端末と失敗する端末で、同じストアの内容を並べて比較します。中間 CA の有無だけが違うのであれば、本不具合の症状と整合する材料になります。

中間 CA 証明書による回避策

切り分けの結果、本不具合への該当可能性が高いと判断したら、次の順序で対応します。Fortinet と FortiOS 7.6.7 の Release Notes が示す回避策は、端末側への中間 CA 証明書の導入です。

参考: FortiOS 7.6.7 Release Notes
“Install the intermediate CA on the trusted store on the endpoint manually”
（エンドポイントの信頼されたストアへ中間 CA を手動でインストールします。）
https://docs.fortinet.com/document/fortigate/7.6.7/fortios-release-notes/236526/known-issues

出所が確認できない CA 証明書を信頼ストアへ追加すると、その CA が署名した証明書をすべて信頼することになります。取得元が不明な証明書は導入しないでください。

多数端末へ展開する場合の注意

対象端末が多い環境では、1 台ずつ手作業でインポートする運用は現実的ではありません。Active Directory のグループ ポリシーや MDM など、既に運用している端末管理基盤の証明書配布機能を利用することを検討します。具体的な配布手順は基盤ごとに異なるため、利用する製品の公式ドキュメントで確認してください。

配布先ストアの指定を誤ると、中間 CA がルート CA として扱われる、あるいは意図しない端末にも配布されるといった状態になります。配布対象と配布先ストアを事前に定義し、小規模なグループで検証してから広げる進め方を推奨します。

修正版への更新とロールバックの判断

7.6.8 と 8.0.1 の公開状況

Fortinet Community は、本件が今後の FortiOS 7.6.8 と 8.0.1 で解決される予定と記載しています。ただし、これは Community 記事上の記載であり、各バージョンの公開状況とは別の論点です。

執筆時点で Fortinet Document Library のバージョン一覧に表示される最新版は FortiOS 7.6.7 と 8.0.0 であり、7.6.8 と 8.0.1 の Release Notes および Resolved Issues は確認できませんでした。現時点では修正済みバージョンではなく、Fortinet が修正予定として示しているバージョンとして扱ってください。

Fortinet Community が示す Scope は FortiOS 7.6.7 です。8.0.1 が解決予定に挙がっていることだけを理由に、FortiOS 8.0.0 も影響を受けると判断しないでください。

Resolved Issues と Upgrade Path を確認する

修正版が公開された後も、バージョン番号だけを見て更新するのではなく、次の内容を確認してから計画を立てます。

• 対象バージョンの Resolved Issues に Bug ID 1304588 が掲載されているか
• 自機種と現行バージョンからの推奨アップグレードパス
• 更新前のコンフィグバックアップと復元手段
• 更新後に、端末へ配布した中間 CA 証明書を残すかどうかの PKI 運用方針
• 更新後に複数端末で IKEv2 接続が成立するかの確認

端末へ配布した中間 CA 証明書の扱いについては、次項で整理します。将来の修正版へ更新する際の推奨アップグレード経路と所要時間の確認方法は『FortiGate アップグレードパスの確認方法と所要時間｜HA 構成の手順』で扱っています。

Fortinet の当該構成例では、必要な下位 CA 証明書をクライアント端末にも配置する構成が示されています。修正版への更新後に中間 CA 証明書を維持するかは、自組織の証明書チェーン、配布方法、PKI ポリシーに基づいて判断します。

あわせて、更新前には対象バージョンの Known Issues 全体に目を通しておくと安全です。FortiOS 7.6.7 周辺では、アップグレードに伴う別の不具合も公開されています。詳細は『FortiOS 更新後の設定消失｜Bug ID 1277454 の回避手順』で扱っています。

7.6.6 へ戻す場合の注意

Fortinet Community は、7.6.6 へ戻すと接続が回復する事例を症状の一つとして挙げています。ただし公式の回避策は端末への中間 CA 導入であり、ロールバックが第一選択として示されているわけではありません。

前提として、FortiOS の Release Notes は、以前のファームウェアへのダウングレードが全モデルで設定消失を伴うと説明しています。保持されるのは動作モード、インターフェース IP と管理 IP、スタティックルートテーブル、DNS 設定、管理者アカウント、セッションヘルパー、システムアクセスプロファイルに限られます。

参考: FortiOS 8.0.0 Release Notes
“Downgrading to previous firmware versions results in configuration loss on all models”
（以前のファームウェアへのダウングレードは、全モデルで設定の消失を招きます。）
https://docs.fortinet.com/document/fortigate/8.0.0/fortios-release-notes/687629/downgrading-to-previous-firmware-versions

あわせて Fortinet Community のダウングレード解説では、ファームウェアのダウングレードはサポートされておらず、TAC も推奨しないとしたうえで、代替手段として次回起動時に別のファームウェアを選択する方法や、TFTP でイメージを書き込む方法が案内されています。

参考: Fortinet Community（ファームウェアのダウングレード）
“Firmware downgrade is not supported and has a high likelihood of causing unexpected issues”
（ファームウェアのダウングレードはサポートされておらず、予期しない問題を招く可能性が高いとされています。）
https://community.fortinet.com/fortigate-3/technical-tip-fortigate-firmware-downgrade-for-minor-releases-148979

したがって、7.6.6 へ戻す判断は、通常のダウングレードを実行するかどうかではなく、更新直前の状態へ復帰できる手段が残っているかどうかから検討します。確認する項目は次のとおりです。

• 7.6.7 への更新直前のファームウェアとコンフィグへ戻せる状態か
• 物理 FortiGate でバックアップパーティションを利用できるか
• FortiGate-VM の場合、更新前スナップショットを利用できるか
• 更新前のコンフィグバックアップが残っているか
• 通常のダウングレードによる設定消失と停止影響を許容できるか
• HA 構成での停止影響をどこまで見込むか
• 判断が難しい場合に Fortinet TAC へ相談するか

Upgrade Path Tool は更新経路を確認するための仕組みであり、ダウングレード経路の確認には使用しません。7.6.6 へ戻す判断の根拠として使わないでください。

FortiOS 7.6.6 が一般的に安全な推奨バージョンというわけではありません。7.6.7 で解消された他の不具合やセキュリティ対応が戻ることの影響も含めて、自環境の要件に照らして判断してください。

まとめ

Bug ID 1304588 は、FortiOS 7.6.7 の IKEv2 証明書認証で、中間 CA 証明書が証明書ペイロードに含まれない場合がある不具合です。設定ミスに見えやすく、端末ごとに成否が分かれるため切り分けに時間がかかりますが、確認すべき点は FortiGate 側と端末側の 2 つに整理できます。

• 対象は FortiOS 7.6.7 の IKEv2 と証明書ベースの署名認証
• send-cert-chain が有効でも中間 CA が送信されない場合がある
• 必要な中間 CA を保持しない端末で認証に失敗する可能性
• FortiOS バージョン、IKE バージョン、認証方式、設定値の確認
• 成功端末と失敗端末で中間証明機関ストアを比較する切り分け
• 公式の回避策は正規の中間 CA 証明書を端末へ導入すること
• 7.6.8 と 8.0.1 は修正予定であり、公開状況は個別に確認

以上、最後までお読みいただきありがとうございました。