平成31年春 午後Ⅱ 問1 設問6 について教えてください。

設問6 (1) i について 
IPAの公式解答では、
i: 「信頼するCAのディジタル証明書」
となっていますが、「ルート証明書」ではだめなんでしょうか？

図5の2. 「社内PCとFW1とのTLSセッションの確立」について
(2) 「W1は、ディジタル証明書及び対応する秘密鍵を作成する。」
ですが、これは、
FW1が外部WebサーバへのHTTPSリクエストを検出した際に、外部Webサーバの
FQDNを保持し、FW1が発行した自己署名証明書のコモンネームを外部Webサーバの
FQDNに書き換えたデジタル証明書を動的に作成する。FW1のディジタル署名
作成用の秘密鍵は共通。
この認識で合っているでしょうか？

設問6 (2) j について
IPAの公式解答では、
j: 「クライアント証明書の掲示が必要な外部Webサーバに接続する。」
となっています。
制約の原因として、「社内PCがもっているクライアント証明書に対応した
秘密鍵を利用することができない。」
とありますが、ここで疑問です。
上の 図5 2.(2) で外部サーバのデジタル証明書を動的に
作成したように、FW1で自己署名証明書からクライアント証明書を動的に
作成し、自身の秘密鍵を利用すれば、クライアント証明書の掲示ができる
ように思いますが、それではなぜだめなんでしょうか？
だめな理由を教えてください。
よろしくお願いします。

>設問6 (1) i について 
>IPAの公式解答では、
>i: 「信頼するCAのディジタル証明書」
>となっていますが、「ルート証明書」ではだめなんでしょうか？
これについては表現の問題です。「ルート証明書」では今一つな感じです。
「【信頼する】ルート証明書」のほうがよいです。
ちなみにWindowsの証明書ストアでは「信頼されたルート証明機関」という
名前になっています。
しかしIPAの表現の問題なので、次に同一の問題がでたら
「信頼するCAのディジタル証明書」と答えるようにしてください。
もう一つ付け加えるのであれば、2年ほど前から
「ディジタル」->「デジタル」と表記が改められました。
したがって、今であれば
「信頼するCAのデジタル証明書」が最適解になります。

>図5の2. 「社内PCとFW1とのTLSセッションの確立」について
>・・・
>この認識で合っているでしょうか？
すみません。誤解されているようです。図5の説明どおり、ここでFWはネットワーク
中継機器として機能します。
FW1は事前に用意された、FW1の名前がコモンネームとして入っている自己署名証明書を
もっているのみです。
動的に証明書を作成したりしません。

>設問6 (2) j について
>・・・
>上の 図5 2.(2) で外部サーバのデジタル証明書を動的に
>作成したように、FW1で自己署名証明書からクライアント証明書を動的に
>作成し、自身の秘密鍵を利用すれば、クライアント証明書の掲示ができる
>ように思いますが、それではなぜだめなんでしょうか？
>だめな理由を教えてください。
>よろしくお願いします。
すみません。ここも誤解されているようです。
もしFW1が動的に自己署名証明書を作成したとします。しかし動的に作成された
自己署名証明書は社内PCの「信頼するCAのディジタル証明書」として
登録されていません。そのため、動的に作成されたFW1の自己署名証明書は
検証に失敗します。

pixさん、いつも素速い回答ありがとうございます。

>「信頼するCAのデジタル証明書」が最適解になります。
承知しました。

>FW1は事前に用意された、FW1の名前がコモンネームとして入っている自己署名証明書を
>もっているのみです。
>動的に証明書を作成したりしません。
取り急ぎ、1点だけ確認させてください。
FW1の名前がコモンネームとして入っている自己署名証明書を社内PCが
検証する時に、コモンネームがFW1だと接続先の外部Webサーバと
異なるので、社内PCで警告が出たりしないのでしょうか？

すみません。私の認識が誤っていたようです。
No.2の説明は誤っております。訂正いたします。

>(2) 「W1は、ディジタル証明書及び対応する秘密鍵を作成する。」
>ですが、これは、
>FW1が外部WebサーバへのHTTPSリクエストを検出した際に、外部Webサーバの
>FQDNを保持し、FW1が発行した自己署名証明書のコモンネームを外部Webサーバの
>FQDNに書き換えたデジタル証明書を動的に作成する。FW1のディジタル署名
>作成用の秘密鍵は共通。
>この認識で合っているでしょうか？
動的に作成するのは自己署名証明書ではないです。
自己署名証明書をルートCAとして、そのルートCAから動的にデジタル証明書を発行する
ということと考えられます。

>設問6 (2) j について
>IPAの公式解答では、
>j: 「クライアント証明書の掲示が必要な外部Webサーバに接続する。」
>となっています。
>・・・
>ように思いますが、それではなぜだめなんでしょうか？
>だめな理由を教えてください。
>よろしくお願いします。
クライアント証明書とはクライアントが本物であることを確認するものです。
クライアント証明書の作成は接続先のサイトが事前に作成し、PCにインストールします。
また、一般的にはPCにインストールしたら取り出せないです。
FW1が勝手に作成できるものではないです。

>動的に作成するのは自己署名証明書ではないです。
>自己署名証明書をルートCAとして、そのルートCAから動的にデジタル証明書を発行する
>ということと考えられます。
すみません。図5 2.についてもう1回確認させてください。((1)～(3)は図5 2.に対応)
(1)FW1が外部WebサーバへのHTTPSリクエストを検出した際に、外部Webサーバの
 FQDNを保持し、宛先IPアドレスを変換し、FW1を終端として社内PCとの間で
 TLSセッションの確立を開始する。
(2)FW1は、デジタル証明書及び対応する秘密鍵を作成する。(詳細は下記の通り)
 FW1が発行した自己署名証明書をルートCAとして、そのルートCAが署名した
 デジタル証明書(CN(コモンネーム)は外部WebサーバのFQDNを設定)と対応する
 秘密鍵を作成する。
(3)FW1は、作成したデジタル証明書及び対応する秘密鍵を利用して社内PCとFW1との間でTLSセッションを確立する。(詳細は下記の通り)
 社内PCとFW1との間のTLSハンドシェイクで、FW1が作成したデジタル証明書を
 社内PCに送信し、社内PCがその証明書を検証する。検証に問題無ければ
 TLSハンドシェイクが終了し、TLSセッションが確立する。
この認識で合っているでしょうか？
あと、1点質問があります。
(3)で、FW1が送付したデジタル証明書を社内PCが検証する際、
名前の確認(証明書のSAN/CNのFQDNと接続先の外部WebサーバのFQDNの照合)は、
上記の通りCNに外部WebサーバのFQDNを設定しているので問題無いと思いますが、
実際の送信元は、外部WebサーバでなくてFW1です。これは、一致していなくても
デジタル証明書の検証で問題にならないのでしょうか？

TLSクライアント証明書については別途

>この認識で合っているでしょうか？
はい。あっています。

>あと、1点質問があります。
>・・・
>実際の送信元は、外部WebサーバでなくてFW1です。これは、一致していなくても
>デジタル証明書の検証で問題にならないのでしょうか？
考え方が逆になります。
デジタル証明書の検証は
1.証明書チェーンの検証（信頼するCAからデジタル証明書が発行されているか）
2.証明書の期限
3.アクセス先FQDNと証明書のCN（SAN）が一致しているか
の3点です。
特に、FW1が動的に証明書を発行するのは「3.アクセス先FQDNと証明書のCN（SAN）が
一致しているか」のつじつまを合わせるためです。

また、FW1が証明書を動的に生成していますが、クライアント側はこの証明書が
外部WebサーバからかFW1からかを区別する情報はありません。
そのため、一致している・していないというよりも検査のしようがないというのが
実際のところです。

デジタル証明書は「1.証明書チェーンの検証」が一番信頼の元となります。
「信頼するCAのデジタル証明書」にルートCAとして証明書を追加するということは
そこから発行されたデジタル証明書は絶対的に信頼するという意味になります。

>特に、FW1が動的に証明書を発行するのは「3.アクセス先FQDNと証明書のCN（SAN）が
>一致しているか」のつじつまを合わせるためです。
>
>また、FW1が証明書を動的に生成していますが、クライアント側はこの証明書が
>外部WebサーバからかFW1からかを区別する情報はありません。
>そのため、一致している・していないというよりも検査のしようがないというのが
>実際のところです。
わかりました。「信頼するCAが発行したデジタル証明書」だから、名前が一致
していればOKということですね。

>TLSクライアント証明書については別途
TLSクライアント証明書についても何となくわかりました。

>上の 図5 2.(2) で外部サーバのデジタル証明書を動的に
>作成したように、FW1で自己署名証明書からクライアント証明書を動的に
>作成し、自身の秘密鍵を利用すれば、クライアント証明書の掲示ができる
>ように思いますが、それではなぜだめなんでしょうか？
FW1が、仮にクライアント証明書と秘密鍵を作成したとしても、
外部サーバで、クライアント証明書のデジタル署名が検証できず、
クライアント証明書の検証ができない。
(FW1の自己署名証明書が、外部Webサーバの「信頼するCAのデジタル証明書」として
登録されてないから)
FW1が、社内PCのクライアント証明書と秘密鍵を入手すれば可能だが、秘密鍵は
社内PCのTPMに保管する等厳重に管理されていて取り出せない。
よってクライアント証明書の掲示が必要な外部Webサーバに接続する場合は、
FW1でのHTTPS復号は不可能。
間違っているところがあれば指摘いただきたく。
よろしくお願いいたします。

>間違っているところがあれば指摘いただきたく。
>よろしくお願いいたします。
クライアント証明書として有効な証明書はWebサーバ側で発行元が厳密にきめられています。
そのためFW1が勝手に証明書を発行したととしても、有効な証明書としてみなされません。
たとえFW1の自己署名証明書を外部Webサーバの「信頼するCAのデジタル証明書」として
登録してもダメです。

>FW1が、社内PCのクライアント証明書と秘密鍵を入手すれば可能だが、秘密鍵は
>社内PCのTPMに保管する等厳重に管理されていて取り出せない。
秘密鍵の保護はTPMではなく、OSによって取り出しができないように管理されています。
ですが、最近のOSならばOS自信がTPMに秘密鍵を格納して管理している可能性はあります。

またFW1に社内PCのクライアント証明書と秘密鍵を集めたとしても、HTTPリクエスト時に
どの社内PCの証明書を利用するかという問題や、そもそも秘密鍵を社内PCから持ち出す
というのはセキュリティ倫理に反する行為なので、対応するのは不適切と思われます。

>クライアント証明書として有効な証明書はWebサーバ側で発行元が厳密にきめられています。
>そのためFW1が勝手に証明書を発行したととしても、有効な証明書としてみなされません。
>たとえFW1の自己署名証明書を外部Webサーバの「信頼するCAのデジタル証明書」として
>登録してもダメです。
わかりました。

あと、もう1点だけ確認させてください。
図4の社内PCとFW1のTLハンドシェイクで、図では社内PCとFW1が直接通信
しているように見えますが、実際にはIPレベルでプロキシサーバが中継
しているので、
>また、FW1が証明書を動的に生成していますが、クライアント側はこの証明書が
>外部WebサーバからかFW1からかを区別する情報はありません。
社内PCが受信したデジタル証明書が、外部Webサーバから送られたものか
FW1から送られたものかを送信元からは判別できないということですよね？

>社内PCが受信したデジタル証明書が、外部Webサーバから送られたものか
>FW1から送られたものかを送信元からは判別できないということですよね？
ここでいう「送られたもの」というのは、FW1が動的に生成したものか、それとも
外部サーバが元からもっていたのものかという意味です。
送り元についてではありません。
この2つを区別する方法はないと思われます。

>ここでいう「送られたもの」というのは、FW1が動的に生成したものか、それとも
>外部サーバが元からもっていたのものかという意味です。
>送り元についてではありません。
>この2つを区別する方法はないと思われます。
わかりました。

で、TLSハンドシェイクの相手についても、社内PCは外部Webサーバだと
思っていて、実際にはFW1が終端していても(プロキシサーバが中継しているし)
社内PCではわからない。
この認識で合ってますでしょうか？

>で、TLSハンドシェイクの相手についても、社内PCは外部Webサーバだと
>思っていて、実際にはFW1が終端していても(プロキシサーバが中継しているし)
>社内PCではわからない。
>この認識で合ってますでしょうか？
その認識でよいと思われます。特にプロキシが中継している・していないは
関係はないと思われます。

矛盾する発言で恐縮ですが、社内PC側で敢えてTLSコネクション先がFW1というのを
検出すれば、FW1と通信していることは識別できます。
しかし、本環境の目的はFW1のHTTPS復号機能のため、FW1がTLSレイヤでTLS中継用
プロキシとして働くことです。
これは悪意ある偽装ではなく、正規の目的のための中継です。
そのため、社内ではFW1経由の通信が一旦中継されることは公に知られてよいことに
なります。

スレ主様はFW1で中継されていることを社内PC側に見えないようにすることを
望まれているようです。ですが、中継という観点からは通信に矛盾がなく目的が
達成できればよいのではという判断になります。

わかりました。
HTTPS復号機能について理解が深まりました。
長々とお付き合いいただきありがとうございました。