3 Minutes NetWorking Supplement
No.19

3Minutes NetWorking Supplement

補講第19回PKI(6) トラストアンカと信頼モデル

■ 電子証明書の弱点

おねーさん

おね〜さんと、

ほげたん

ほげたんのっ!!

おねーさん

3 Minutes Networking、

ほげたん

Supplement !!

おねーさん

さてさて、前回の話を要約すると、「ねぇ、その公開鍵って信頼できるの?」という疑問の解決だったわけね。

ほげたん

それはちょっと要約しすぎのような。つまり、電子証明書とCAの登場だね。

おねーさん

それも要約しすぎ。公開鍵のなりすましは公開鍵暗号化システムを破綻させるがスタートね。それを防ぐため、電子証明書とCAが登場したわけでしょ。

ほげたん

うん。公開鍵の所有者を保証する電子証明書とそれを発行するCAだね。

おねーさん

そういうことね。

ほげたん

んでもさ、これでOKなんじゃないの? 前回は邪悪な……もとい、含み笑いで終わったんだけど? 「まだ足りない」ってドコが?

おねーさん

んふふ。前回のコレ見てもらおっかな。

公開鍵のなりすましの防止

[FigureSP18-08:公開鍵のなりすましの防止]

ほげたん

? なりすましを防ぐために、CAの保証がある電子証明書しか受け取らない、でしょ? 問題ないじゃん?

おねーさん

逆に言うならば、電子証明書ならば受け取る、と考えられるわね。

ほげたん

う…うん、そうとも言える、かな?

おねーさん

でしょう? んでね、こうなる。

[FigureSP19-01:電子証明書を使ったなりすまし

ほげたん

…、ところでさ。このブラックほげたんは、ブラックネットさんに協力を仰いでまで僕になんでなりすましとかしようとするのかな?

おねーさん

恨みでもかってるんじゃない? 「お前は俺の心をズタズタにした!! 今度は俺がお前をズタズタにしてやるっ!!」とか

ほげたん

あ、あぁ。俺は人殺しがだぁ〜い好きなんだ!!、ってことかな?

おねーさん

まぁ、そんな脳が痛い話は置いておいて。なりすましできたでしょ?

ほげたん

い、いや、これは…。ブラックネットさん、つまり悪いCAが存在して、なりすましの電子証明書を発行するってのはちょっと予想外というかなんというか。

おねーさん

電子証明書ってね、そんなに特別なものじゃないのよ。WindowsサーバOSがあれば、あっという間にできるわね。前に出てきたopensslがあっても結構簡単にできるわよ。

ほげたん

そ、そうなの?

おねーさん

別にブラックネットさん率いる悪いCAに頼まなくても、その気になれば自分でも作れるってことね。つまり、前回の「公開鍵って信用できるの?」の解答が「電子証明書が保証するよ」だったでしょ?

ほげたん

だったね。公開鍵とその所有者を結びつけるのが電子証明書だったから。

おねーさん

それで「電子証明書が保証する」っていうけど、さっきの例みたいに悪いCAが発行したり、自分で作ったりしたら「保証」も何もないでしょ?

ほげたん

そうだね。なりすましするための電子証明書が存在しちゃうわけだから。

おねーさん

つまり、電子証明書の正当性の保証が必要ってこと。悪いCAや自作で電子証明書が作られてない、正当なCAによる発行したってことを証明してよ、って話。

ほげたん

正しいCAが発行した電子証明書じゃなきゃ困るってことだね。

■ トラストアンカ

おねーさん

ここでのポイントは「正当なCAによる発行かどうかをどうやって判断するか」よね。

ほげたん

そうだね、悪いCAが発行したり、自作だったりじゃなくて、「ちゃんとしたCAが発行した電子証明書だ」って識別できないと、なりすまし電子証明書をつかまされる恐れがあるよね。

おねーさん

そのためには、「正当なCA」ってのを、利用者が知っていなければいけないわけよね。つまり、なりすまし電子証明書を発行したりするような悪いCAじゃないCAはコレって知ってなきゃダメってこと。

ほげたん

うん、それはわかる。その前に、「利用者」ってどっち? 電子証明書を使う方? もらう方?

おねーさん

あ、あぁ。そうね。その区別はこう。

所有者と利用者(依拠当事者)

[FigureSP19-02:所有者と利用者(依拠当事者)]

ほげたん

電子証明書を発行してもらって、渡す側が「所有者」、受け取って検証する側が「利用者」。依拠当事者って?

おねーさん

あ、うん。前に紹介したIPAの文書だと、「利用者(証明書利用者)」なんだけど。CAだと「依拠当事者」って呼んでることが多いのよ。それでね、困ったことに「依拠当事者」って呼ぶ場合は所有者は「利用者」って呼んだりするのよ。

ほげたん

うわ、ややこしい。

おねーさん

なので、ここでは「所有者」と「依拠当事者」って呼ぶことにするわね。

ほげたん

あいあい、了解。

おねーさん

さて、話を戻して。受け取った電子証明書が正当なCAから発行されているかどうか。これは発行元CAが依拠当事者にとって「信頼」できるCAかどうかってことになるわけよ。

ほげたん

ん? 依拠当事者にとって?

おねーさん

そう。正当なCAからの発行じゃないと困るのは依拠当事者だからね。まぁ、最終的には所有者にも影響があるかもしれないけど、直接的に「なりすまし」「改ざん」「否認」を防ぎたいのは依拠当事者の方でしょ?

ほげたん

まぁ、そうかな。電子証明書をもらって、検証をしっかりして、なりすましやらなにやらがないって保証されたいのはデータをもらう方だよね。

おねーさん

でしょ。で、依拠当事者が「CAを信頼する」ことが必要なの。で、信頼したCAが発行した電子証明書は信頼できるって流れになるわけね。

ほげたん

ちょ、ちょっと待って。整理させて。電子証明書が正当性の保証が必要。それは正当なCAが発行したかどうか、である。…依拠当事者にとって、信頼しているCA=正当なCAってことでいいのかな?

おねーさん

そういうことね。でね、信頼できるCAかどうかは依拠当事者が決める。ここでのポイントは自己署名証明書よ。

ほげたん

自己署名証明書? CAが自分の公開鍵の署名前証明書を、自分の秘密鍵で署名した証明書だよね?

おねーさん

それそれ。だってさ、ほげたん? 自己署名証明書なんてカッコイイ言い方してるけどさ。これって「自分で自分のサインを証明する書類」なのよ? こんな莫迦なことないじゃない?

ほげたん

まぁ、そうかなぁ。

おねーさん

あれよね、言うならばオレオレ証明書よね。「これが僕の印影です。ホンモノだという証明に、ほら、ここに僕の捺印があるでしょ?」 こんな保証も何もあったもんじゃない書類を使って、電子証明書を検証するのよ?

ほげたん

でも自己署名証明書がなきゃ、検証できないよね。

おねーさん

そう。自己署名証明書をCAから貰わないといけない。それを貰って、検証に使うって、もうCAを信頼してないとできないことよね?

ほげたん

そうだね、その「オレオレ証明書」、保証もないような証明書を信じて使うしかないよね。

おねーさん

つまり、CAの自己署名証明書を持っている=そのCAを信頼しているとなる、というわけね。

ほげたん

そうなる、のかな? 持っていること、イコール信頼なの?

おねーさん

まぁ、持っていても信頼しないって事もないわけじゃないけど。基本的に自己署名証明書を貰うってことは、「信頼しているから」じゃないとできないわけだからね。この、自分が自己署名証明書を持っているCAのことを、トラストアンカと呼ぶの。

ほげたん

アンカー? 船の錨のことだよね。トラスト、信頼の錨?

おねーさん

そう、依拠当事者が信頼するCAをそう呼ぶの。そのCAが依拠当事者にとって、信頼が固定されている場所だからね。ま、あとの「信頼モデル」でなんで「アンカー」って呼ぶかわかるわ。

ほげたん

信頼しているCA=トラストアンカ。ってことは、トラストアンカが発行した電子証明書は、トラストアンカが「所有者とその鍵の結びつき」を保証しているから、正当な電子証明書である、ってことかな。

おねーさん

その理解でOK。それを踏まえて、電子証明書の検証をおさらい。

[FigureSP19-03:自己署名証明書と電子証明書

おねーさん

前回も話したけど、3回の検証が行われているわね。

  1. CAの電子証明書の改ざんの確認
  2. 送信者の電子証明書の改ざんの確認とCAが発行したという認証
  3. 送信者の署名データによる改ざんの確認と送信者が作成したという認証
おねーさん

(1)の、自己署名証明書の検証。これ、改ざんの確認に行うんだけど。普通、検証っていったら(2)(3)にある通り認証が入るはずなんだけど、ないのはなんで?

ほげたん

え? え〜っと、自己署名だから?

おねーさん

そう。自己署名だから、なりすましの対策である認証が意味をもたないことになっちゃってるのね。ちなみに、改ざんもやりようによってはできちゃうわ。

[FigureSP19-04:自己署名証明書のなりすましと改ざん

ほげたん

ををを。自己署名証明書ってほぼ無検証で受け入れちゃうんだ。

おねーさん

そうね、この場合の「改ざんの検出」ってのは、署名まで改ざんしてない場合の、署名前証明書の改ざんの検出であって。署名まで改ざんされちゃうと手も足もって事ね。

ほげたん

で、いったんそのなりすまされた自己署名証明書を受け取っちゃうと、そのCAをトラストアンカとしちゃうから、そこが作った電子証明書はすべて検証OKになっちゃう、と。怖いね。

おねーさん

でしょう? よって、トラストアンカにしたいCAの自己署名証明書はなりすましや改ざんがない安全な方法で受け取るのが必要ってことね。

ほげたん

安全な方法? どんなの?

おねーさん

手渡し、郵送がまず物理的な手法としてあげられるわよね。あとは、証明書を使用するソフトをインストールする際に一緒にインストールしちゃうとか。

ほげたん

へぇ。ソフトウェアのインストーラに組み込んでおくんだ。

おねーさん

そう。他にもCAのWebサイトで公開して。一緒に改ざん防止のために、自己署名証明書のダイジェストを載せておいて、検証してもらうとかね。たとえば、ベリサインだとこんな感じ。 ▼ link

自己署名証明書のフィンガープリント

[FigureSP19-05:日本ベリサイン 自己署名証明書のフィンガープリント]

ほげたん

この「フィンガープリント」ってところだね。ダウンロードした自己署名証明書のダイジェストを自分で作って、これと比較すればいいんだね。…これって安全なの?

おねーさん

すくなくとも、Webサイトを改ざんしないとダメだしね。ともかく、なんらかの手段を用いて安全に自己署名証明書を受け取らないとダメってことね。

ほげたん

なるほど。

おねーさん

でね。トラストアンカでないCAから発行された電子証明書を受け取った場合は、警告がでるのが一般的ね。

トラストアンカでないCAから発行された電子証明書

[FigureSP19-06:トラストアンカでないCAから発行された電子証明書]

ほげたん

「問題があります」。「信頼された証明機関から発行されたものではありません」、だって。

おねーさん

この場合、SSLのサーバを証明する電子証明書を受け取ったんだけど。それがトラストアンカでないCAから発行された電子証明書なわけね。だから、「問題あるよ」という警告がでたわけ。

ほげたん

あー、でも。「このサイトの閲覧を続行する」ってあるよ。推奨されないけど。

おねーさん

あとは自己責任って感じね。それと、さっきの(2)の「送信者の電子証明書の改ざんの確認とCAが発行したという認証」ね。自己署名証明書のCAの公開鍵による電子証明書の検証を行うってこと。

ほげたん

それにより、改ざんの確認と、トラストアンカが発行した電子証明書であることが保証されるわけだね。

おねーさん

そういうことね。電子証明書の署名はCAが行っているから、署名による認証によりCAが発行したかどうかわかるって寸法ね。

ほげたん

それにより、「電子証明書の保証」が行われるわけだね。

■ CAの信頼モデル

おねーさん

さて、トラストアンカの話を前提として次の話。
CAと所有者と依拠当事者がいるでしょ。これって、「CAという信頼」を中心につながっているといえるでしょ?

ほげたん

ん? いまいち意味がわからないよ。

おねーさん

CAがあって、所有者がCAに発行してもらって、それを依拠当事者に渡す。依拠当事者はCAを信頼してその電子証明書を検証する。こういう関係よね。

ほげたん

そうだね。CAと所有者と依拠当事者の関係はそうだよね。

おねーさん

世界に1つだけCAがあって、世界中の人がそのCAを使ってるんならまだしも。世界にはいっぱいCAがあるの。こっちのCAを使っている人と、そっちのCAを使っている人はどういう関係?

ほげたん

どういうって言われても。特に関係ないんじゃないじゃないかなぁ。

おねーさん

うん。実は全く関係ない。CAの信頼の範囲はあくまでも所有者と依拠当事者にしか及ばないのね。

CAの信頼の範囲

[FigureSP19-07:CAの信頼の範囲]

おねーさん

図のCA1が影響するのは、左のA、Bの二人だけ。CA2が影響するのは右のC,Dの二人だけ、ね。これはこれでいいんだけど、たとえばAがDに署名付きデータを送りたい場合どうするの?

ほげたん

Aが持っている電子証明書はCA1が発行した奴で、DにとってはCA1はトラストアンカじゃないから、「トラストアンカ以外が発行した証明書」扱いになっちゃうから。DがCA1をトラストアンカにするか、受け取らないか、どっちかじゃない?

おねーさん

うんうん、その通り。これが全く関係ないCA同士ならいいけど、例えばA社とA社の人が利用しているCA。B社とB社の人が利用しているCA。A社とB社が提携して、電子文書のやり取りをして、署名が必要になりました。こういう場合はどうしよう?

ほげたん

どうしよう、って。A社の人はB社のCAを、B社の人はA社のCAを、それぞれトラストアンカにすればいいんじゃない?

おねーさん

それはそうね。でも、それだとA社の人がそれぞれB社のCAをトラストアンカに設定して、という面倒な作業が発生しちゃうわね。もうちょっと、こうCAの連係がとれないものかしら?

ほげたん

CAの、連携?

おねーさん

そう、連携。これをCAの信頼モデルっていうんだけど。要はCA同士が信頼しあうことね。

ほげたん

へぇ、そうするとなんかいいことあるの?

おねーさん

それについてはモデルの説明でしていくわ。さてさてっと、このモデル。5種類あるのでそれぞれ説明していくわね。

  1. 個別認証(単独CA)モデル
  2. 階層型モデル
  3. Webモデル
  4. メッシュ(相互認証)モデル
  5. ブリッジCAモデル
おねーさん

まず最初が「個別認証モデル」ね。これは一番シンプルな方式で、それぞれトラストアンカを設定するモデルね。

個別認証モデル

[FigureSP19-08:個別認証モデル]

ほげたん

ふむふむ。あれだね、この図の例だと、BさんはAさん、Cさんから電子証明書をもらうから、それぞれCA1、CA2をトラストアンカに設定しておくんだね。

おねーさん

そうそう。CAは自己署名証明書を作成し、依拠当事者はその自己署名証明書を入手して、CAごとにトラストアンカとして設定する。ま、いままでの説明通りのものね。

ほげたん

だね。っていうか、これ以外というのが思いつかないんだけど。

おねーさん

ま、それは説明してくから。これはシンプルなモデルだけど、使われるCAをすべて個別に信頼しなくちゃいけないって点でちょっと面倒なわけね。

ほげたん

う〜ん。そう言われればそうかな。

おねーさん

次が「階層型モデル」。これは親子関係にあるCAで、親CAをトラストアンカに設定するモデル。

ほげたん

親子関係? CAが?

おねーさん

そう。親会社と子会社とか。グループとそのグループ参加企業とか、そういうイメージね。この階層モデルでは親CAが子CAを信頼し、証明書を発行するのね。

[FigureSP19-09:階層型モデル]

ほげたん

え、ええ? ま、まず。親CAが子CAの公開鍵を保証する電子証明書を発行する

おねーさん

そう。そして、子CAが発行した電子証明書はその親CAの署名が入った子CAの電子証明書で検証する。それにより、「自己署名証明書により親CAを保証」→「親CAが子CAを保証」→「子CAが所有者を保証」という信頼のつながりが形成されるわけね。

ほげたん

トラストアンカが発行した電子証明書はトラストアンカが「公開鍵と所有者の結びつき」を保証しているよね。でも、今回のはトラストアンカが発行してないけど?

おねーさん

確かにそうね。でも、今話した「信頼のつながり」がそれと同等の意味を持つのよ。

信頼のチェーン(階層型)

[FigureSP19-10:信頼のチェーン(階層型)]

おねーさん

これを信頼のチェーンもしくは証明(認証)パスと呼ぶの。たとえトラストアンカが発行していなくても、このトラストアンカへのチェーンができていれば電子証明書は保証されていると考えるの。

ほげたん

へぇ、保証が連鎖していって、「トラストアンカが保証した」ことになるんだね。

おねーさん

そうね、だからチェーンと呼ばれるわけね。チェーン(鎖)の先には錨(アンカー)があるわけ。

ほげたん

チェーンとアンカー。なるほどね、だから「信頼の錨(トラストアンカ)」か。

おねーさん

そういうこと。この時、親CAを「ルートCA」と呼ぶの。ここから、階層構造であってもなくてもトラストアンカをルートCAと呼ぶのね。

ほげたん

階層型(ツリー)の根(ルート)にあるから、ルートCAだね。

おねーさん

この階層構造の利点はわかるわよね、ルートCAさえトラストアンカとしていれば、すべての子CAが発行する電子証明書は保証される。つまり、個別にCAを信頼しなくて済む、わけね。

ほげたん

そうだね。親会社さえ信頼していれば、すべての子会社も信頼されるって感じでいけるわけだね。

おねーさん

そうそう。だけど弱点もあって。親CAが信頼できないCAになっちゃうと、すべての子CAがダメになるし。逆に子CAが信頼できないCAであっても、親CAを信頼しちゃうとすべて信頼されてしまう。信頼関係がしっかりしてないとダメってことね。

ほげたん

CAが信頼できないようになることってあるの?

おねーさん

あるわよ。それは次回の話にしましょう。次のモデルの説明ね。「Webモデル」。これは現在インターネットで一般的に使われている信頼モデルのこと。主にSSLのサーバ証明とメールでブラウザ・メーラが使用するモデルね。

ほげたん

ブラウザが? SSLってアレだよね。HTTPで主に使われている暗号・認証プロトコル。

おねーさん

そう。Webモデルは個別認証と階層型の両方が使われているモデルね。ポイントはインターネットで信頼のおけるCAが事前にトラストアンカとしてブラウザに登録されているってこと。

ほげたん

ブラウザに登録されている?

おねーさん

そうよ。つまり、ブラウザのベンダ、Microsoftであったり、Mozilla Foundationだったり、Appleだったり、そこが事前にトラストアンカとしていくつかのCAを登録してくれているのね。例えば、IEだったらこんな感じ。

IE7に登録されたトラストアンカ

[FigureSP19-11:IE7に登録されたトラストアンカ]

ほげたん

ははぁ。ってことは、SSLやメール暗号化につかう電子証明書のCAとして、わざわざ自己署名証明書を入手しなくてもいいわけなんだね。

おねーさん

逆にいえば、ここに載っているCA以外から、電子証明書を発行してもらった場合、依拠当事者にそのCAの自己署名証明書を登録してもらわなきゃダメってこと。なので、普通ココに載っているCAを使うのよ。簡単だし、登録してもらう必要もないから。

ほげたん

そういえば、さっき、「個別認証と階層型の両方」っていってたけど?

おねーさん

WebモデルのルートCAとして、1つのCAでやってる場合もあるし、ベリサインみたいに大きなところはベリサインCA群で階層構造になってるわけ。例えば前回取得した電子証明書だと、こんな感じ。

ベリサインパブリックサービスの信頼のチェーン

[FigureSP19-12:ベリサインパブリックサービスの信頼のチェーン]

おねーさん

前回発行してもらった電子証明書の発行元は「VeriSign Class 1 Individual Subscriber CA」。で、これの親CAが「VeriSign Class 1 Primary CA」。ブラウザはこの「VeriSign Class 1 Primary CA」をトラストアンカとしてるの。

ほげたん

へぇー。信頼のチェーンってこんな風に表示されるんだね。

おねーさん

Webモデルについては、また話すわ。で、次のモデル、「相互認証モデル」。さっきの階層型だと、「親子関係のCA」だったわね。でも、別々の独立したCAが提携した場合とかだと、「親子」にならないでしょ? あくまでも「提携」なんだから。

ほげたん

そうだね。たぶん、どっちが「親」になるかで揉めそうだね。

おねーさん

そういう時に使われるのが、相互認証モデル。独立したCA同士が信頼しあう形ね。それぞれが相手のCAに対し電子証明書を発行するの。

[FigureSP19-13:相互認証モデル]

ほげたん

相互認証証明書? さっきの親CAが子CAの公開鍵を保証する電子証明書に似てるね。

おねーさん

というか、基本的には役割は同じね、相手のCAの公開鍵を保証する電子証明書よ。これにより信頼のチェーンを形成するわけね。

信頼のチェーン(相互認証)

[FigureSP19-14:信頼のチェーン(相互認証)]

ほげたん

さっきの階層型が水平になった感じだね。

おねーさん

そうね。これで、自分のトラストアンカが相互認証しているCAが発行した電子証明書は検証できるようになるってことね。さっきの階層型同様、いちいち個別にCAを信頼しなくていいわけ。

ほげたん

うんうん。自社のCAだけトラストアンカとしておけば、提携企業グループ内だったら検証が可能になるってことだね。

おねーさん

でもね、ほげたん。例だとCAが2つだけだからいいけど、10社とかあったらどうなる? とある会社のCAは他9社と相互認証しなきゃいけない。つまりフルメッシュ型になるのよ?

ほげたん

10個のCAがそれぞれ他のCAと相互認証するとなると、相互認証が複雑になるよね。

信頼のチェーンの複雑化

[FigureSP19-15:信頼のチェーンの複雑化]

おねーさん

そうよね。図だと5つのCAだけど、相互認証の数も多いし、依拠当事者BがトラストアンカとしているCA3から、所有者Aまでのチェーンが通るパスもいくつもできてしまって、複雑になり、どのパスを使っていいかわからなくなってしまう。

ほげたん

ルーティングみたいだね。

おねーさん

そこで、最後の1つ。「ブリッジCAモデル」。ブリッジCAという中継点を使って相互認証を行う方式ね。

[FigureSP19-16:ブリッジCAモデル]

ほげたん

ははぁ、間にBCAをはさんで、相互認証をする方式なんだ。

おねーさん

そう、それぞれのCAはBCAとのみ相互認証を行うことにより、BCAを挟んだ相互認証の形を作るってことね。信頼のチェーンもBCAを間にはさんで作られるわけ。

信頼のチェーン(ブリッジCA)

[FigureSP19-17:信頼のチェーン(ブリッジCA)]

おねーさん

このBCAを使うと、CAの数が多い場合でも相互認証の数も減るし、信頼のチェーンも1つのパスしか作られなくなるわけ。

信頼のチェーンの単純化

[FigureSP19-18:信頼のチェーンの単純化]

ほげたん

うん、ずいぶんとシンプルになったよね。

おねーさん

実際、大規模な相互認証モデルはこのBCAを使うのが普通ね。さて、と。なんか今回は長かったわ。とりあえずまとめると、「電子証明書の保証をトラストアンカが行う」ってこと。

ほげたん

…なんか、今回の説明はその一言で要約された気になってきたよ。

おねーさん

そうねぇ、かなりの量で説明したけど、結局はそんだけのような気がしないでもないわ。
信頼モデルの話も、「トラストアンカが『所有者と公開鍵の結びつき』を保証する範囲を広げる」だけだしね。

ほげたん

トラストアンカと、親子だったり相互認証だったりするけど、信頼関係を結んだCAが発行した電子証明書は「トラストアンカが保証した」ってことになるわけだね。

おねーさん

そういうことね。

ほげたん

だよね。でもこれで、電子証明書も保証されて、もうなりすましも改ざんも否認も起きなくなったわけでしょ。よかったよかった。で、おね〜さん次回は?

おねーさん

ん〜〜〜〜。

ほげたん

ま、またその邪悪な、じゃなくって、含み笑い? 何? まだダメなの? 足りないの?

おねーさん

足りないっていうか。まだ大事なことが抜けてるの。

ほげたん

……さっぱり想像つかないよ。もうOKだと思うんだけどなぁ…。

おねーさん

んふふ。それは次回のおたのしみ、ね。
おね〜さんと、

ほげたん

ほげたんのっ!!

おねーさん

3分間ネットワーク、

ほげたん

サプリメントでした〜〜〜っ!!

依拠当事者
[Relying Party]
「証明書利用者」も同じ英訳。
所有者
[Certificate Holder]
トラストアンカ
[Trust Anchor]
信頼点、もしくは信用点とも呼ぶ。
ルートCA
[Root CA]
ルート認証局、ルート証明機関とも。
IEだったら
「インターネットオプション」→「コンテンツ」タブ→「証明書」ボタン→「信頼されたルート証明機関」タブ。または、Microsoft管理コンソール(MMC)から、「証明機関」でも調べられます。
相互認証証明書
[Cross Certificate]
ほげたんほげたんの今日のポイント
  • 電子証明書の正当性を保証する必要がある。
    • 信頼するCAであるトラストアンカが保証する。
    • 自己署名証明書をもつCAがトラストアンカとなる。
    • 自己署名証明書は安全に配布されなければならない。
  • CA間で信頼関係を結ぶことにより、トラストアンカによる保証範囲を広げることができる

3 Minutes NetWorking Supplement No.19

管理人:aji-ssz(at)selene.is.dream.jp