No286 「友だちの友だちは皆友だちだ」理論

今回は、前回の続きとなりますが、ルート証明書と中間証証明書について解説を行います。

中間証明書などと言っても「そんなの聞いたことない」という方が多いと思いますが、実際には皆さんも日常的に気付かないうちに使っておられるはずです。

こういった証明書の処理はChromeやEdgeといったインターネットブラウザの裏側で行われています。そのため、エラーにならない限りは表に出てくることはほとんどないため、ご存知ない方が多いのです。

サーバ証明書（前回のおさらい）

少々くどくなりますが、前回のお話を少し補足しながらおさらいしておきます。

インターネット上での安全な通信というと暗号化がよく引き合いに出されますが、それ以前に通信相手がホントに本物か？を検証しなくてはなりません。

その検証手順はHTTPSなどのプロトコル（通信手順）として規定されています。

この規定では、相手のサーバ目的のサーバであることを識別するための「サーバ証明書」が必要となります。
逆に、サーバ側が接続元が許可されたものかどうかを確認するための「クライアント証明書」というものもあります。
サーバ証明書やクライアント証明書には、証明してくれる組織による電子署名を必ず付けることになっています。

この証明してくれる組織のことを「証明機関」や「認証局」、「発行局」などと呼びます。（この記事では認証局と書きます）

認証局は、必ず自分自身の機関証明書であるルート証明書（ルートCA証明書、CA証明書とも呼ばれます）を公開することになっています。

サーバ証明書、クライアント証明書、ルート証明書は目的によって呼び方は違っていますが、内部構造は同じで以下のデータが含まれます。
　１）証明したいデータ（例えばサーバの情報）
　２）上記のデータの正しさを証明する機関（認証局）による電子署名

例えば、サーバ証明書であればサーバ情報が正しいか？また電子署名がルート証明書の情報と一致しているか？といったことを確認した上でサーバとの通信を開始するルールとなっています。

ルート証明書（前回のおさらい）

この中で、ルート証明書だけはちょっと妙な点があります。

ルート証明書への署名は自分自身で行って良いことになっているのです。
ルート証明書に限っては自分で自分を証明するということが許されているのです。

ですが、自分で自分を証明っていうこと自体がおかしな話ですし、誰でも認証局やルート証明書が作れてしまいます。

何よりも問題なのは、ChromeやEdgeといったインターネットブラウザで、ニセモノのルート証明書が識別できないことになります。
ニセモノのルート証明書を検出できないということは、その認証局が発行したサーバ証明書もニセモノかどうかがわからないということになります。

これ自体は大変な問題ですが、実に単純な方法でこれはクリアされています。
インターネットブラウザには主要なルート証明書をあらかじめ組み込んであるのです。

インターネットブラウザの開発元が信頼に値すると考えた数十個のルート証明書が最初
から入った状態で配布されているから、ブラウザは信頼できるサーバ証明書かどうかが識別できるというわけです。

でも、現実にはたくさんの認証局が...。

上で、ブラウザには数十のルート証明書が含まれていると書きました。

ですが、サーバ証明書を発行している会社は全世界に何百、何千とあります。

では、それらの認証局で発行したサーバ証明書を使うとインターネットブラウザは「信頼できないサイトだ」と判断するのでしょうか？

いえいえ、そうはならずにちゃんと正しいサイトとして表示されます。

これには「証明書チェイン」という仕組みと中間証明書についての説明が要ります。

「友だちの友だちは皆友だちだ」理論

いきなり妙な章タイトルですが、証明書チェインを一言で言うとまさに「友だちの友だちは皆友だちだ」理論となります。

つまり、ルート証明書を保持している認証局Ａがあるとします。

ここに新参の認証局Ｂが登場したとしましょう。

認証局Ｂもルート証明書を保持していますが、その証明書はどのブラウザにも入っていませんから、結局は信頼できない認証局扱いとなります。
そのため、認証局Ｂに署名してもらったサーバ証明書を持つサイトＣは「信頼できないサイト」となってしまいます。

そんな不名誉なサーバ証明書を欲しい人はいませんから、これでは認証局Ｂのビジネスが成立しません。

そこで、認証局Ｂは自己署名ではなく、認証局Ａに署名してもらった「認証局Ａの署名付きのルート証明書」という特殊なルート証明書を作ります。

これを中間証明書と言います。

つまり、サイトＣの正しさは認証局Ｂが、認証局Ｂの正しさは認証局Ａが、認証局Ａの正しさはブラウザ内蔵のルート証明書が証明してくれるという理屈です。

このように中間証明書を使って関接的にサイトＣが正しいことを証明することを「証明書チェイン」と呼びます。

で、最初に戻ります。
以上から、証明書チェインのことを筆者は「友だちの友だちは皆友だちだ」理論と呼んでいます。

この中間証明書はたくさんの組織で使われています。

例えばサーバ貸しやクラウドサービスなどを提供している会社ではレンタルをしているお客さん向けにサーバ証明書の発行サービスがありますが、その多くは中間証明書です。

また、CyberTrustのようにそこそこ名の知れた認証局でも中間証明書でビジネスを展開している会社もあります。

証明書チェインの例

証明書チェインの例として、筆者の所有するegao-it.com の証明書チェインを見てみます。
※　Subjectは証明したい内容、Issuerは署名をした組織名を示します。
　実際にはもう少し繁雑な記述ですが、ここでは簡略化しています。

まず、egao-it.comのサーバ証明書の内容。
　Subject: egao-it.com
　Issuer: JPRS Domain Validation Authority

次に、上記に署名したJPRSの中間証明書の内容。
　Subject: JPRS Domain Validation Authority
　Issuer: Security Commiunication RootCA2(SECOM Trust Systems)

最後に、ブラウザに含まれているSECOM社のルート証明書
　Subject: Security Commiunication RootCA2(SECOM Trust Systems)
　Issuer: Security Commiunication RootCA2(SECOM Trust Systems)

この証明書チェインの場合、ブラウザはこんな順で内容の検証を行います。

最初にサーバ証明書のSubjectを確認ます。
このSubjectに書かれた egao-it.com という名称は今からアクセスしようとしているサイト名と一致いますから問題ありません。
また、そのIssuerを確認して、署名したのがJPRSという組織だというのがわかります。

次に中間証明書（これはサーバがサーバ証明書とセットにしてブラウザに渡します）を確認します。
このSubjectを見ますと、JPRSという名前が書かれています。これはサーバ証明書のIssuerと一致します。
また、そのIssuerを確認すると、署名したのがSECOMという組織であることがわかります。

さて、このSECOMという組織が信頼できるのであれば、中間証明書が信頼でき、さらにサーバ証明書も信頼できることになります。

ブラウザは、このSECOMという組織のルート証明書がブラウザ内に登録されているかどうかを確認します。
この場合は、ルート証明書が登録されていますので、結果としてサーバ証明書が正しいことが判断できるというわけです。

恐ろしく面倒ですがブラウザはページを表示する都度、この手順を踏んでいるのです。

さて、上記の例では中間証明書は１つだけでしたが、２つ以上の中間証明書を経由する場合もあります。複数の証明書を経由したとしても、最終的にブラウザに登録されているルート証明書に辿り着くことができれば、「友だちの友だち」なので信頼できる、というわけです。

（余談：なぜ自己署名なのか？）

（本章については、文献が見つけられなかったため、全て余談としています）

ここまでで、どうして自己署名などという妙な構造にしたのか？と思われる方もおられると思います。

証明書チェインがあるんだから、最初に権威のある認証局を一つ作り、全てはその認証局に辿れるようにしておけばいいじゃないか、という考え方です。

確かにこの考え方は一般的ですし、むしろ効率は良いと筆者も思いますが、残念ながら全く「インターネット的」ではありません。

ご存知の方もおられると思いますが、もともとインターネットやその原型となったArpaNet（アーパネット）は徹底的な分散型システムの実現方法として考案されました。

敵からの攻撃を受けてネットワークに被害があっても、被害を受けていない部分は機能するシステムという意味です。

そのため、インターネットには司令塔のような権限を集約した機構がありません。
司令塔があれば、そこに被害を受けた時にネットワーク全体に支障をきたすためです。

権威のある認証局というのも同様です。
そこにトラブルがあると、証明書チェイン全体が影響を受け、インターネットとして機能しなくなる可能性があります。

それを起こさないため、各々が自己署名をする形式となったようです。

さらに余談：オレオレ証明書
　システム開発ではテスト用認証局を作ることがあります。
　こういったテスト用認証局は「なんちゃって認証局」、この認証局で作ったサーバ証明書を「オレオレ証明書」などと呼びます。
　いわゆるオレオレ詐欺から取ったネーミングなのですが、どなたが言い始めたのか知りませんが、秀逸なシャレだと思います。
　

まとめ

信頼できるルート証明書はインターネットブラウザに含まれ、ブラウザはそれを使ってサーバ証明書などの署名が正しいことを検証しています。

ですが、世の中にはサーバ証明書を発行してくれるサービスは何百何千とあるのに、ブラウザに含まれるルート証明書は数十しかありません。

にも関わらず、ブラウザは多くのサーバ証明書を「信頼できる」と判断できています。
これには、信頼できる認証局が発行した中間証明書は信頼できる。その中間証明書の認証局が発行したサーバ証明書も信頼できる」という「友だちの友だちは皆友だちだ」と同様の考え方にもとづく証明書チェインという考え方に基づいています。

実際に、世の多くのWebサイトで中間証明書が用いられています。
筆者の所有する egao-it.com のサイトでも中間証明書が用いられています。

興味のある方は是非ブラウザで証明書を確認してみてください！と言いたいところですが、どのブラウザでも証明書関連の表示はプロ向けっぽくて、ひどくわかりにくいのが困ったものです。

前回と今回の二回にわけ、ルート証明書と証明書チェインについて解説をしました。
次回もお楽しみに。

（本稿は 2022年12月に作成しました）

本Noteはメルマガ「がんばりすぎないセキュリティ」からの転載です。
当所はセミナーなどを通して皆さんが楽しく笑顔でITを利用いただくために、 難しいセキュリティ技術をやさしく語ります。
公式サイトは https://www.egao-it.com/ です。