設問3（2）
「D社の認証局が万が一何らかの原因で不正操作された場合を想定して...」
不正操作されれば特定PCに限定しても意味ないのではないでしょうか？

本問を理解するには
・信頼されたルートCAのルート証明書
・証明書チェーンの検証
・自営CA
の3つの知識が必要です。
そのため、解説が長文になるのはご容赦ください。

普段使用しているWindowsPCには事前にDigiCertやGlobalSignやSECOMなどの大手の
ルート証明書が「信頼されたルートCAのルート証明書」として、インストール
されています。
これはMicrosoftがDigiCertやGlobalSignやSECOMは信頼できると判断し、責任を
もっているからです。

これら大手から発行されたサーバ証明書を持つWebサイトにアクセスした際に、
クライアントPCはWebサイトのサーバ証明書とクライアントPC内の信頼されたルートCAの
ルート証明書が適切に紐づくか（これを証明書チェーンの検証）を確認します。
紐づけばサーバ証明書は本物と判断されます。
紐づかない場合はサーバ証明書は偽物と判断され、Webブラウザに信頼されない
サーバ証明書として警告画面が表示されます。

自営CAですが、これは大手のルートCAではなく、自社で運営する認証局を意味します。
ここまでが基礎知識になります。

本問はD社では「D社ルートCA」、「CA-3」という自営CAを運用しています。
これらのCAは自身の
D社ルートCA：ルート証明書
CA-3：中間証明書
を公開しています。

取引先から専用PCでJシステムにアクセスする際、Jシステムから
・サーバ証明書
・中間証明書
の2枚が送られてきます。
・専用PCに「D社ルートCAのルート証明書」が導入済の場合
  D社ルートCAのルート証明書が存在するため、サーバ証明書・中間証明書の
  証明書チェーンの検証に成功し、正常にアクセスできる
・専用PCに「D社ルートCAのルート証明書」が未導入の場合
  D社ルートCAのルート証明書が存在しないため、サーバ証明書・中間証明書の
  証明書チェーンの検証に失敗し、Webブラウザで警告画面が表示される
という結果になります。

ここからが本題になります。
質問は「D社の認証局が万が一何らかの原因で不正操作された場合を想定して...」
とあります。
これはD社のCA-3が不正アクセスを受け、乗っ取られた場合と考えられます。
乗っ取られたCA-3からはCA-3が発行元の不正なサーバ証明書を好きなだけ発行
できます。
極端な例をあげれば、CA-3から"www.google.com"のサーバ証明書も発行できます。
攻撃者はこの不正発行されたサーバ証明書とDNSキャッシュポイズニングを行って、
偽の"www.google.com"サイトを作成し、PCを不正にアクセスさせることもできます。

通常であれば、CA-3の親になるD社ルートCAのルート証明書が入っていない
PCがこの偽サイトにアクセスしても、証明書チェーンの検証で失敗し、
エラー画面が表示されます。

しかし、D社ルートCAのルート証明書が入ってるPCは、この偽サイトにアクセスした時、
証明書チェーンの検証に成功してしまい、本物と思い込んでアクセスしてしまいます。

このように自営CAが乗っ取られ、不正なサーバ証明書が発行された場合に影響範囲を
小さくするために、D社ルートCAのルート証明書の導入先を限定しておく必要がある
というのが本問の解答の趣旨になります。

SCでは証明書技術の知識は必須になります。しかし、証明書技術は複雑な点が多いので
慣れていないと理解するのは大変です。

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

”これはMicrosoftがDigiCertやGlobalSignやSECOMは信頼できると判断し、責任を
もっているからです。”
ブラウザにインストールされているのでMicrosoftだけではないかと思います。

結局は不正なサーバにアクセスするリスクはとりのぞけない、ということでよろしいでしょうか

>ブラウザにインストールされているのでMicrosoftだけではないかと思います。
これは具体的にはどのようなケースなのでしょうか？
ブラウザからインストールしても、OS側で一括で管理されています。
管理されている証明書は、Microsoft管理コンソールから確認できます。
また、Webブラウザから信頼するルートCAのルート証明書が勝手にインストール
されることはないです。

>結局は不正なサーバにアクセスするリスクはとりのぞけない、
>ということでよろしいでしょうか
ルート証明書は
・Microsoftが自動的にインストールする
・手動で明示的にインストールする
しかないです。

できれば、不明点を具体的に教えていただけないでしょうか？

＞これは具体的にはどのようなケースなのでしょうか？
chromeだとgoogleではないでしょうか？

”このように自営CAが乗っ取られ、不正なサーバ証明書が発行された場合に影響範囲を
小さくするために、D社ルートCAのルート証明書の導入先を限定しておく必要がある
というのが本問の解答の趣旨になります。”
影響範囲が小さくなるだけで、不正なサーバにはアクセス可能になるかと思います。

>>これは具体的にはどのようなケースなのでしょうか？
>chromeだとgoogleではないでしょうか？
話を理解するためにWindowsを例として挙げています。
OSがWindowsで、WebブラウザがGoogle Chromeだとします。
信頼されたCAのルート証明書を管理しているのは、Windowsになります。

>>”このように自営CAが乗っ取られ、不正なサーバ証明書が発行された場合に影響範囲を
>>小さくするために、D社ルートCAのルート証明書の導入先を限定しておく必要がある
>>というのが本問の解答の趣旨になります。”
>影響範囲が小さくなるだけで、不正なサーバにはアクセス可能になるかと思います。

自営CAのルート証明書がPCに導入されている場合、その子となるCAから
発行されたサーバ証明書は無条件で信頼することになります。

そのため、自営CAのルート証明書がPCに導入されている場合、偽サーバに
アクセスした際に、Webブラウザで証明書チェーンの検証に成功してしまい、
警告画面がでることなくアクセスしてしまいます。
これによりユーザは偽サーバにアクセスしていること自体に気付きません。

しかし、自営CAのルート証明書がPCに導入されていなければ、偽サーバに
アクセスした際に、Webブラウザで証明書チェーンの検証に失敗し、
Webブラウザに「サーバ証明書が不正」という警告画面が表示されます。
この警告画面により、ユーザは偽サーバにアクセスしたことに気付くことができます。
敢えて、警告を無視して強引に偽サーバにアクセスすることはやろうと思えば可能です。

そのため、不用意にJシステムにアクセスする必要のないPCにも自営CAのルート証明書が
導入されていると、偽サーバに接続したときに警告画面がでなくなり気付けなくなる
という影響が広がってしまいます。

そのため、自営CAのルート証明書を導入するPCはできる限り数を少なくし、
CAがのっとられて不正なサーバ証明書が発行された際の影響を少しでも、
小さくしたいというのが設問の趣旨になります。

Windowsが証明書ストアで管理しているルート証明書とは別に、
Chromeが独自に信頼しているルート証明書もあるようですよ。

>PAC3さん
Chrome105（半年くらい前）からOSのルートストアを使用するのでなく、
独自のルートストアに移行しているみたいですね。
まだベータで完全に移行は完了していないのでしょうか？
貴重な情報ありがとうございます。

GoogleとMSで信頼するCAのポリシーに差異が発生したのでしょうか。
MS側で信頼するCAのルート証明書の更新が遅いから、Googleが独自に実装したと
思われます。
自動更新されるルート証明書についてはMS側とChrome側で別個に更新されそうです。

自営CAのルート証明書に関しては、手動で両方のストアに入れる必要が今後は
発生することになるかもしれないです。