別にRFCで定義されているわけでもないですし、ブラウザの実装次第でいくらでも回答が変わりますよね。
代表的なブラウザChromeやIEがこのような表示をしているのでしょうか？
不思議な問題でした。

質問は『令和５年【秋】 午後 問2 【設問1】(2)c,d』でしょうか。

一般的に証明書の検証項目として以下の4項目が挙げられます。
・証明書チェーン（信頼されているCAから発行されているか）
・FQDNと証明書のCNの一致
・証明書の失効（CRL,OCSP)
・証明書の期限
ブラウザによって、文言は異なりますが、この4つを検証するのはWebブラウザとして
デファクトスタンダードです。

ありがとうございます！理解いたしました

@pixさん
すみません、私もこの設問の解答には疑問持ってます。
接続するサイトのサーバ名(FQDN)と証明書に記載しているサーバ名が異なるというのは理解できないです。
1,偽サイトを用意するときには、偽サーバのFQDNを正規サーバのFQDNに設定できないですか？
2,偽証明書CNには偽サイトのサーバ名を設定できないですか？
設定できれば、エラーメッセージが表示されないと考えています。設問の中では特に偽サーバのサーバ名や偽証明書のCNが設定間違ってるとは見当たらないですね。

いつも丁寧に回答して下さって、本当に感謝します。よろしくお願いします。

すみません。具体的内容が汲み取れなかったので、わかる範囲で解答いたします。

>1,偽サイトを用意するときには、偽サーバのFQDNを正規サーバのFQDNに
>設定できないですか？
とても細かい話になりますが、一般的なWebサーバにはFQDNを設定する箇所は
ありません。FQDNと似たものでServerNameというものはあります。しかし
FQDNとは役割が異なります。
そのため、偽サイト自体にFQDNを設定する必要はありません。

FQDNはDNSのAレコードでIPアドレスと紐づけるために設定されます。
クライアントはDNSクエリでFQDNを正引きしてIPアドレスを取得します。
したがって、FQDNを認識しているのはクライアント側ということになります。

このDNSクエリで名前解決する時に、DNSキャッシュポイズニングなどで不正な
IPアドレスを返すことで、クライアントはFQDNのIPアドレスの紐づけを誤解する
ことになります。

あとは、この不正なIPアドレスにアクセスし、証明書を取得した際に
クライアント側で自分が接続したと認識しているFQDNと証明書のCNを比較して
差異がないかをチェックします。

>2,偽証明書CNには偽サイトのサーバ名を設定できないですか？
偽証明書のCNを偽サイトのサーバ名に設定することは簡単です。
・プライべート認証局から証明書を発行
・自己署名証明書を作成
これらの方法で簡単にできます。

この証明書ならば、クライアントが認識しているFQDNと証明書のCNは一致します。
そのため、「FQDNと証明書のCNの一致」はパスします。
しかし、この証明書は正規のCAから発行されたものではないので、
「証明書チェーン」の検証で失敗します。

以上のように証明書の真正性の根拠として一番重要なのは「証明書チェーン」の
検証です。
攻撃者がどんなに周到に準備しても、正規のCAから発行された証明書（厳密には
証明書と秘密鍵）を入手できないかぎり、証明書チェーンの検証が失敗します。

この証明書チェーンの検証によって、いくら偽の証明書を準備したとしても
確実に見破られるという事実が、証明書の安全性を担保している根拠の大元と
なります。

補足いたします。
証明書技術については、
・以下の3つの名前違いと使われるOSI階層
DNSでのFQDN
証明書のCN
WebサーバのServerName

・一般的なWebサーバの設定方法、
特にServerName,VirtualHost,SNI

・一般的なWebサーバへのアクセス方法
サーバへのアクセスは全てIPアドレスで行われる
IPアドレスを知るにはFQDNをDNSクエリで正引きする必要がある

これらすべての知識を有していることが、
証明書技術を正確に理解するために必要になります。

度々の補足失礼いたします。
さらに細かいことを言えば、
クライアントからアクセスする際に以下にFQDNがセットされます。
・HTTP ホストヘッダー
・TLSのSNI
この値はWebサーバ側でServerNameと照合されます。
そういった意味ではFQDN = ServerNameと考えてもよいかもしれません。

しかし、Webサーバ側でVirtulHostがない場合は、デフォルトホストに
接続するため、FQDNとしてのServerName設定は必須ではないです。

偽サイトであれば、なおの事VirtualHostを持つ意味ないので
FQDNとしてのServerNameの設定は意味がないと考えられます。

@pixさん
本当に感謝いたします。解説してくださって、理解できました。
こちらで確認したかったのは偽サーバ証明書のCNに正規サイトのFQDNを設定したら、設問の中のFQDNが異なるというエラーメッセージは出なくなることです。結論は偽AP、偽DNS、偽サイトを用意しても、最後では証明書チェーンのチェックで失敗します。
問題文には特に偽サーバ証明書のCNに違うFQDNを書いてるとの記述はなくて、FQDNが異なる答えが導きにくいなぁと思います。
ただし、自分の疑問をクリアできていて、感謝します。
ありがとうございます！