【FortiGate】FortiDDNSの更新失敗でFortiClient VPNがFQDN接続できない｜証明書エラーの切り分けと復旧

FortiGateのFortiGuard Dynamic DNS（FortiDDNS）を利用して、FortiClient VPNのリモートゲートウェイをFQDNで指定している環境で、突然VPN接続ができなくなりました。

今回発生した事象を簡単にまとめると、以下のような流れです。

FortiGateのWAN側グローバルIPが変更
        ↓
FortiDDNSが新しいIPアドレスへの更新を試みる
        ↓
FortiGuard DDNSとのSSL/TLS通信で証明書エラー
        ↓
DDNSレコードが古いグローバルIPのまま更新されない
        ↓
FortiClientがFQDNから古いIPアドレスへ接続
        ↓
VPN接続失敗

VPN機能そのものには問題がなかったため、FortiClientのリモートゲートウェイを現在のグローバルIPアドレスへ直接変更することで、一時的にVPN接続を復旧させることができました。

その後調査したところ、FortiGuard DDNSへの更新処理で証明書関連のエラーが発生していることが分かりました。

Fortinetからも2026年9月3日付で、複数のFortiOSバージョンにおいてFortiGuard DDNSの更新に失敗する事象が公開されています。記事執筆時点では調査中とされています。

今回は、実際に行った切り分けと復旧までの流れを紹介します。

※本記事に掲載しているFQDN、グローバルIPアドレス、シリアル番号など、環境固有の情報はすべて架空の値またはマスキングした値へ置き換えています。

---

今回発生した事象

FortiClient VPNの接続先として、FortiGateのFortiDDNSで取得したFQDNを指定していました。

例として、以下のFQDNを使用していたものとします。

vpn-example.fortiddns.com

FortiClientのリモートゲートウェイには、このFQDNを設定しています。

リモートGW：
vpn-example.fortiddns.com

通常であれば、FortiGateのWAN側グローバルIPが変更された場合でもFortiDDNSが自動的にDNSレコードを更新します。

FortiGuard DDNSは、動的に変化する外部IPアドレスに対して固定のドメイン名を使用するための機能です。

しかし今回、あるタイミングからFortiClient VPNへ接続できなくなりました。

---

FortiClientの接続先をIPアドレスにすると接続できた

まずVPN自体に問題があるのかを切り分けるため、FortiClientのリモートゲートウェイをFQDNではなく、現在FortiGateに割り当てられているグローバルIPアドレスへ変更しました。

実際のグローバルIPは掲載できないため、ここではドキュメント用アドレスを使用します。

203.0.113.10

FortiClientを以下のように変更します。

変更前：
vpn-example.fortiddns.com

変更後：
203.0.113.10

すると、VPN接続に成功しました。

この時点で、

FortiClient
   ↓
インターネット
   ↓
FortiGate
   ↓
VPN接続

という通信自体には問題がなく、FQDNの名前解決周辺に問題がある可能性が高いと判断しました。

---

nslookupでFortiDDNSを確認する

続いて、FortiDDNSのFQDNがどのIPアドレスを返しているのか確認します。

Windows PCから以下を実行します。

nslookup vpn-example.fortiddns.com

ここで返ってくるIPアドレスと、現在FortiGateに割り当てられているグローバルIPアドレスを比較します。

今回の環境では、

FortiGateの現在のWAN IP
203.0.113.10

FortiDDNSが返しているIP
＜変更前の古いグローバルIP＞

という状態になっていました。

つまり、

FortiGateのグローバルIPは変更されているのに、FortiDDNS側のDNSレコードが更新されていない

ということです。

これでFortiClientがFQDN指定の場合だけ接続できない理由が分かりました。

---

FortiGateのDDNS状態を確認する

FortiGateでは、以下のコマンドでFortiDDNSの状態を確認できます。

diagnose test application ddnscd 3

また、DDNSの詳細な動作を確認する場合はデバッグを有効化します。

diagnose debug reset
diagnose debug console timestamp enable
diagnose debug application ddnscd -1
diagnose debug enable

FortinetのAdministration Guideでも、DDNSのトラブルシューティング用として diagnose debug application ddnscd -1 と diagnose test application ddnscd 3 が案内されています。

確認が完了したら、忘れずデバッグを停止します。

diagnose debug disable

---

DDNSサーバーへの接続自体は成功していた

今回取得したログでは、FortinetのDDNSサーバーの名前解決には成功していました。

環境固有情報をマスクすると、概ね以下のようなログです。

received dns resolution for ddns.fortinet.net: 173.243.138.226

DDNS id:1,
server:FortiGuardDDNS,
domain:vpn-example.fortiddns.com,
active intf:wan

Interface address changed.

Add ddns entry
(intf:wan
 server:FortiGuardDDNS,
 domain:vpn-example.fortiddns.com,
 interface ip:203.0.113.10)

さらに、

connected to 173.243.138.226:443

となっています。

ここが重要です。

このログから、

ddns.fortinet.netの名前解決：成功
        ↓
173.243.138.226への通信：成功
        ↓
TCP/443への接続：成功

というところまでは正常であることが分かります。

つまり単純な、

• DNS障害
• デフォルトルート不備
• インターネット接続障害
• TCP/443の遮断

ではなさそうです。

---

証明書のhostname mismatchが発生していた

さらにログを確認すると、次のエラーが発生していました。

enable hostname checking 'ddns.fortinet.net'.

Cert error 62, hostname mismatch. Depth 0

Certificate verification failed,
error 62 (hostname mismatch)

CN=sdns.fortinet.net

SSL_connect failes:
certificate verify failed

failed to establish SSL connection

注目するのは、

ddns.fortinet.net

へ接続しようとしているのに、相手から提示された証明書が、

CN=sdns.fortinet.net

となっている点です。

つまり、

接続先として期待：
ddns.fortinet.net

提示された証明書：
sdns.fortinet.net

となっており、ホスト名が一致していません。

その結果、

error 62 (hostname mismatch)

となり、SSL/TLS接続が確立できず、FortiDDNSの更新処理にも失敗していました。

最終的には以下のように記録されています。

Failed on update FortiGuardDDNS
(vpn-example.fortiddns.com),
due to internal/config/connect/io err

2026年5月にもFortinet Communityで、ddns.fortinet.net への接続時に CN=sdns.fortinet.net が提示され、error 62 (hostname mismatch) となる類似事象が報告されています。

---

FortinetからFortiGuard DDNSの問題が公開されていた

調査したところ、Fortinet Communityに以下のTechnical Tipが公開されていました。

Technical Tip: FortiGuard DDNS fails to update

2026年9月3日に公開された情報で、複数のFortiOSバージョンにおいてFortiGuard DDNSへの接続に失敗し、DDNSエントリを更新できなくなる可能性があるとされています。

Fortinetが掲載している代表的なエラーは次のものです。

error 19 - self-signed certificate in certificate chain

error 2 - unable to get issuer certificate

今回実際に確認した hostname mismatch とはエラー内容が異なりますが、FortiGuard DDNS周辺で証明書関連の問題が発生している点では関連します。

Fortinetは記事内で2つの回避策を案内しています。

---

Fortinet公式の回避策①

1つ目は、Certificate Bundleのバージョンを確認し、DigiCertのRoot CAをFortiGateのTrusted Certificateへ取り込む方法です。

まず以下を確認します。

diagnose autoupdate versions | grep -iA 2 Bundle

Fortinetの記事では、Certificate Bundleが以下のバージョン以降であることを確認するよう案内されています。

Certificate Bundle
---------
Version: 1.00064

その上で、

DigiCert High Assurance EV Root CA

をTrusted CertificateとしてFortiGateへインポートします。

---

Fortinet公式の回避策②

2つ目は、FortiGuard DDNSの接続先を変更する方法です。

Fortinetが案内している設定は以下です。

config system fortiguard
    set fortiguard-anycast disable
    set ddns-server-ip 173.243.138.226
end

続いてDDNSクライアントを再読み込みさせます。

diagnose debug application ddnscd -1
diagnose debug enable
fnsysctl killall ddnscd

Fortinetによると、通常利用するDDNSサーバー側で証明書関連の問題が発生する場合の代替手段として、173.243.138.226 への切り替えが案内されています。

173.243.138.225 や 173.243.138.226 は今回の環境固有のグローバルIPではなく、Fortinetの公式Technical Tipに掲載されているFortiGuard DDNS側のIPアドレスです。

---

今回は回避策②から実施してしまった

ここが今回のポイントです。

Fortinetの記事では回避策①と回避策②が案内されていますが、私は最初に回避策②を実施しました。

そのためFortiGateには、

set fortiguard-anycast disable
set ddns-server-ip 173.243.138.226

が設定された状態になりました。

しかし、この状態では先ほど紹介した、

Cert error 62, hostname mismatch

が発生し、DDNSを更新できませんでした。

そこで次に回避策①を実施し、DigiCertのRoot CAをFortiGateへインポートしました。

しかし、それでもDDNSは復旧しませんでした。

---

なぜ回避策①を実施しても直らなかったのか

理由は、回避策②で設定した、

set fortiguard-anycast disable
set ddns-server-ip 173.243.138.226

がそのまま残っていたためです。

今回 .226 への接続で発生していたのは、

CAを信頼できない

という問題ではなく、

接続先ホスト名と
提示された証明書のホスト名が違う

という hostname mismatch です。

そのため、DigiCertのRoot CAを追加しても解決しません。

今回の流れを整理すると、

回避策②を実施
        ↓
173.243.138.226を固定
        ↓
hostname mismatch発生
        ↓
回避策①を実施
        ↓
Root CAは追加された
        ↓
しかし接続先は引き続き173.243.138.226
        ↓
hostname mismatchは解消しない

という状態でした。

---

回避策②の設定を解除したところ復旧

そこでFortiGuardの設定を以下のように変更しました。

config system fortiguard
    set fortiguard-anycast enable
    unset ddns-server-ip
end

つまり、

set fortiguard-anycast disable
set ddns-server-ip 173.243.138.226

という回避策②の設定を解除しました。

するとFortiDDNSの更新が正常に動作するようになりました。

今回の場合、すでに回避策①でDigiCertのRoot CAをFortiGateへ取り込んでいたため、

回避策②
↓
回避策①
↓
回避策②を解除

という操作をした結果、最終的には、

回避策①のみが適用された状態

になったと考えられます。

この状態でDDNS更新が正常に行われるようになりました。

---

FortiDDNSが更新されたことを確認

復旧後、外部PCから再度以下を実行します。

nslookup vpn-example.fortiddns.com

FortiDDNSから返ってくるIPアドレスが、現在FortiGateに割り当てられているグローバルIPと一致していることを確認します。

FortiGate WAN IP
203.0.113.10

vpn-example.fortiddns.com
203.0.113.10

これでFortiDDNSが正常に更新されていることを確認できました。

---

FortiClientをFQDN指定へ戻す

DDNSの復旧を確認したため、暫定的にIPアドレスを直接指定していたFortiClientも元に戻します。

暫定対応：

203.0.113.10

から、

本来の設定：

vpn-example.fortiddns.com

へ変更します。

その状態でFortiClient VPNへ接続し、正常に接続できることを確認しました。

これで今回の障害は復旧です。

---

今回の障害の流れ

今回発生した内容をまとめると、以下のようになります。

FortiGateのWAN側グローバルIP変更
        ↓
FortiDDNSがDNSレコード更新を試行
        ↓
証明書関連の問題でDDNS更新失敗
        ↓
fortiddns.comに古いIPアドレスが残る
        ↓
FortiClientがFQDNを名前解決
        ↓
古いグローバルIPへ接続
        ↓
VPN接続失敗
        ↓
リモートGWを現在のIPへ直接変更
        ↓
FortiClient VPN暫定復旧
        ↓
FortiDDNSを調査
        ↓
Fortinet公式Technical Tipを確認
        ↓
回避策②を実施
        ↓
hostname mismatchで更新失敗
        ↓
回避策①を実施
        ↓
回避策②の設定が残っていたため改善せず
        ↓
回避策②を解除
        ↓
FortiDDNS更新成功
        ↓
FortiClientをFQDN指定へ戻す
        ↓
正常復旧

---

同じ事象が発生したときの切り分け方法

FortiClient VPNへFQDNで接続できなくなった場合、いきなりVPN設定を疑うのではなく、まずFQDNが正しいIPアドレスを返しているか確認するのがおすすめです。

今回の事象であれば、最初に以下を実行するだけでもかなり早く原因へ近づけます。

nslookup ＜FortiDDNSのFQDN＞

その結果とFortiGateのWAN側IPアドレスを比較します。

一致していなければ、FortiDDNSの更新状況を確認します。

diagnose test application ddnscd 3

さらに詳細を確認する場合は、

diagnose debug reset
diagnose debug console timestamp enable
diagnose debug application ddnscd -1
diagnose debug enable

を使用します。

確認後は、

diagnose debug disable

を実行します。

また、FortiGuard側の設定を変更している場合は、

show system fortiguard

で現在の設定を確認しておくことも重要です。

今回のように過去に実施したワークアラウンドが残っていると、その設定自体が次の切り分けを分かりにくくすることがあります。

---

IPアドレス直接指定はあくまで暫定対応

今回、FortiClientのリモートゲートウェイへ現在のグローバルIPを直接指定することで、一時的にVPNを復旧させることができました。

緊急時の暫定対応としては非常に有効でした。

ただし、動的IPアドレスを利用している環境では、再びWAN側IPが変更される可能性があります。

そのため、

IPアドレス直接指定

のまま運用を続けるのではなく、DDNS側の問題を解決したあと、

vpn-example.fortiddns.com

のようなFQDN指定へ戻すことが重要です。

---

まとめ

今回は、FortiGuard DDNSの更新に失敗したことで、FortiClient VPNへFQDN指定で接続できなくなった事例を紹介しました。

一見すると、

FortiClient VPNに接続できない

というVPN障害に見えます。

しかし実際には、

VPNそのもの

ではなく、

FortiDDNSの更新失敗

が原因でした。

特に今回役立ったのは、

FQDN指定 → 接続不可

IPアドレス直接指定 → 接続可能

という切り分けです。

この時点でVPN機能そのものではなく、DNS/DDNS周辺を疑うことができました。

また、今回のようにFortinet公式のワークアラウンドを複数試す場合は、前に実施したワークアラウンドの設定が残っていないか確認することも重要です。

今回の場合、

set fortiguard-anycast disable
set ddns-server-ip 173.243.138.226

が残っていたことで、後から実施した証明書対応の効果を正しく確認できませんでした。

最終的には、

config system fortiguard
    set fortiguard-anycast enable
    unset ddns-server-ip
end

として回避策②を解除したことで、FortiDDNSが正常に更新され、FortiClientも再びFQDN指定で利用できるようになりました。

FortiClient VPNで突然FQDN接続だけができなくなった場合は、

1. nslookupでFQDNのIPを確認
2. FortiGateの現在のWAN IPと比較
3. ddnscdの状態を確認
4. DDNSデバッグを取得
5. Fortinetの既知事象を確認

という順序で切り分けると、原因を見つけやすいでしょう。

参考情報

Fortinet Community
Technical Tip: FortiGuard DDNS fails to update
2026年9月3日公開。FortiGuard DDNSの更新失敗と証明書関連エラー、2種類の回避策が掲載されています。

Fortinet Document Library
DDNS – FortiGate / FortiOS Administration Guide
FortiGuard DDNSの設定方法や ddnscd を利用したトラブルシューティング方法が掲載されています。

Fortinet Community
FortiGuard DDNS Failing
ddns.fortinet.net と sdns.fortinet.net の証明書ホスト名不一致により、VPN用DDNSの更新に失敗した類似事例です。