『[カメラID通信に対する脅威](39検査結果と対応』に記載している内容がうまく理解できているのか自信がありません。
以下の理解で合っているのか教えていただきたくお願いします。

(私の理解１)
『表4の項番1の検査結果：証明書1を使用した場合は通信でき、さらに通信内容を復号して確認することができた。』
→証明書1のCNとクライアントからの接続要求先URLのFQDNが一致していたので通信できた。
Zカメラに証明書1のルート証明書が信頼されたルート証明機関のものと登録されていないので、通常のブラウザであれば「証明書は信頼できません」と表示されるはずが、Zカメラでは証明書が信頼できるか検証していないか、又は検証結果を表示する機能がないかのどちらかが考えられる。

(私の理解２)
『表4の項番1の検査結果：（中略）しかし、証明書2を使用した場合は通信できなかった。』
→証明書1のCNとクライアントからの接続要求先URLのFQDNが一致していないので通信できなかった。

(私の理解３)
『表4の項番2の検査結果：証明書1を使用した場合は、偽クラウド環境に接続させて、Zカメラの操作と動画の受信ができた。』
→DNSキャッシュポイズニング攻撃により、クライアントと偽Zクラウドの間に設置されたTLS終端装置に誘導された。
TLS終端装置に登録された証明書1のCNと、クライアントからの接続要求先URLのFQDNが一致していたので通信できた。
→想定している状況は、「偽Zクラウドのサーバに、不正に入手したZクラウドの正当な証明書が登録されている状況」？？

DNSキャッシュポイズニングの場合、「サーバ証明書を検証することで、接続先サーバの真正性を保証できる」と理解しているので(私の理解３)のところが、うまく整理できていません。
どうぞよろしくお願いします。

>(私の理解１)
>Zカメラでは証明書が信頼できるか検証していないか、
>又は検証結果を表示する機能がないかのどちらかが考えられる。
ここはシンプルに証明書チェーンを検証していないでよいと思います。

>(私の理解２)
>→証明書1のCNとクライアントからの接続要求先URLのFQDNが一致していないので
>通信できなかった。
それでよいと思います。

(私の理解３)
>→DNSキャッシュポイズニング攻撃により、クライアントと偽Zクラウドの間に
>設置されたTLS終端装置に誘導された。
TLS終端装置は項番1で使用する機器です。項番2では使用しないと想定されます。
誘導された先は、偽Zクラウドです。

>→想定している状況は、「偽Zクラウドのサーバに、不正に入手したZクラウドの
>正当な証明書が登録されている状況」？？
すみませんが、想定している状況が異なるようです。
表4中にあるように、ここはテスト用にプライベート認証局から発行された証明書です。
不正に入手したZクラウドの証明書ならば、信頼されるCAから発行されているので
通信エラーは発生しません。

回答ありがとうございます！

>TLS終端装置は項番1で使用する機器です。項番2では使用しないと想定されます。誘導された先は、偽Zクラウドです。

そうですね、表４でもTLS終端装置は項番１でのみ使用のようでした、すみません。
そのうえで、
「偽Zクラウドのサーバに登録された証明書1のCNと、クライアントからの接続要求先URLのFQDNが一致していたので通信できた。」
という理解（←私の理解４）でよろしいでしょうか？

>表4中にあるように、ここはテスト用にプライベート認証局から発行された証明書です。

うまく説明できずにすみません。「想定している状況」で書きたかったことは、「表4の項番2の検査結果で行ったテストは、実際の環境でのどのような攻撃を模しているのか」が疑問に思ったからでした。


（私の理解４）の通りとして、テストで行っている状況を考えてみました。例えば
ZクラウドのIPアドレス：x1.y1.z1.1
ZクラウドのFQDN:aaa.bbb.com

偽ZクラウドのIPアドレス：x9.y9.z9.9
偽ZクラウドのFQDN:zzz.www.com

証明書1のCN：aaa.bbb.com

このときクライアントがZクラウドに接続しようとして、DNSキャッシュポイズニングで偽Zクラウドに誘導され、そして偽Zクラウドには証明書1が登録されている状況ということか読み取りました。
偽Zクラウド(zzz.www.com)に証明書1(aaa.bbb.com)が登録されている・・・、その状況が「？？？」と思い、つたない表現で質問してしまいました。

>「偽Zクラウドのサーバに登録された証明書1のCNと、クライアントからの
>接続要求先URLのFQDNが一致していたので通信できた。」
>という理解（←私の理解４）でよろしいでしょうか？
はい。その理解でよろしいと思います。

>偽ZクラウドのIPアドレス：x9.y9.z9.9
>偽ZクラウドのFQDN:zzz.www.com
偽Zクラウドなので、FDQNは本物と同じ"aaa.bbb.com"でなければいけません。
その点に誤解があるようです。

>偽Zクラウドなので、FDQNは本物と同じ"aaa.bbb.com"でなければいけません。その点に誤解があるようです。

なるほど、、、、そういうことだったんですね。
『表4の項番2の検査』では、
１．DNSキャッシュサーバのAレコードを偽サーバのIPアドレスに書き換える
２．偽サーバのFQDNを正答なサーバのFQDNと同じに設定する
この二つを行っているという状況なんですね。

追加で質問させてください。
DNSキャッシュポイズニング攻撃は１．だけで攻撃が成立すると思っていましたが、１．と２．は必ず対で行うことで成立する攻撃ですか？

先に記載した例では
DNSキャッシュサーバのAレコードに「aaa.bbb.comのIPアドレスはx9.y9.z9.9」と書き換えることに成功すれば、クライアントは「aaa.bbb.com」でアクセスする際には
IPアドレスが「x9.y9.z9.9」であればそのFQDNが何であれ偽サーバに誘導されるのか、
偽サーバがのFQDNがaaa.bbb.comでないと誘導されないのか、どちらなんでしょうか。
よろしくお願いします。

>DNSキャッシュポイズニング攻撃は１．だけで攻撃が成立すると思っていましたが、
>１．と２．は必ず対で行うことで成立する攻撃ですか？
この設問を理解するには、
・DNSのAレコードのFQDN
・証明書のコモンネーム
・WebサーバのバーチャルホストのServerName
これらすべてを理解する必要があります。

>１．DNSキャッシュサーバのAレコードを偽サーバのIPアドレスに書き換える
DNSキャッシュサーバは権威DNSサーバではないので、Ａレコードをもっていません。
DNSキャッシュサーバに嘘のAレコード情報をキャッシュさせます。

>２．偽サーバのFQDNを正答なサーバのFQDNと同じに設定する
前の解答で、便宜的に偽ZサーバのFQDNを本物と同じにすると答えました。
しかし、このFQDNの定義が曖昧なので、問題が複雑に感じているようです。

厳密にはサーバにFQDNを設定する箇所はありません。
ここでいうFQDNとはサーバのホスト名とは別のWebサーバが保持しているものとします。
Webサーバ側でバーチャルホストのServerNameを設定しますが、それが便宜的に
FQDNとして扱われると考えられます。
これは、一般のWebサーバではServerNameと証明書のCNが不一致している場合は
Webサーバは起動しないので、ServerName = FQDNという理解で良いと思います。
しかし、不正なWebサーバであれば、ServerNameと証明書のCNが一致していなくも
起動するでしょうし、そもそも不正なWebサーバであればServerName自体が
不要と考えられます。

>DNSキャッシュサーバのAレコードに「aaa.bbb.comのIPアドレスはx9.y9.z9.9」と
>書き換えることに成功すれば、クライアントは「aaa.bbb.com」でアクセスする際には
>IPアドレスが「x9.y9.z9.9」であればそのFQDNが何であれ偽サーバに誘導されるのか、
>偽サーバがのFQDNがaaa.bbb.comでないと誘導されないのか、どちらなんでしょうか。
偽ZサーバはFQDNがなくても問題ありません。偽ZサーバにはIPアドレスでアクセス
されます。

丁寧な解説ありがとうございます。
曖昧に理解していた箇所がクリアになりました。ありがとうございました！