階層構造の仕組み

SSLサーバー証明書（以下、SSL証明書）を設定してブラウザで確認すると、以下のようにSSL証明書は階層構造になっていることがわかります。

SSL証明書は、上位の証明書が次の証明書に署名し、次の証明書がさらにその次の証明書に署名するという信頼の連鎖（トラストチェーン）で成り立っています。例えば、もし上記のような階層構造の中間に挟まっている証明書が抜けていたり、最上位の証明書が無かったりした場合、この階層構造が崩壊してしまい「example.jp」ドメインは認証されません。認証されない場合、ブラウザにエラー画面が表示され、サイトにアクセスできなくなります。

さて、「認証されずにサイトにアクセスできない」と書きましたが、そもそもSSL証明書がドメインを認証する（SSL証明書を送ってきたサーバーのドメインが、SSL証明書に記載されたドメインと同じであると判断する）仕組みはどうなっているのでしょうか？

例のように「example.jp」のSSL証明書は、サーバーからセットで送られてきた「Example CA intermediate G2」によって署名されていることが検証できます。次に「Example CA intermediate G2」は「Example CA Root X1」によって署名されていることが検証できます。最後の「Example CA Root X1」は、あなたのPC（自身の端末）の中から見つけ出されることで、最終的に「Example CA Root X1」によって「example.jp」ドメインのSSL証明書が正当なものであることが検証できます。

ここで言う「認証」とは通信データを暗号化する仕組みではありません。データの暗号化については、ドメイン認証が行われた後に共通鍵暗号の鍵の素であるプリマスタシークレットの交換を経て初めて可能になりますが、この部分は本記事では触れません。

なお、本記事中では最上位の証明書を「ルート証明書」、間に挟まっている証明書を「中間CA証明書」、ドメインに紐付く証明書を「サーバー証明書」、これらの証明書全体を指して「SSL証明書」と表記します。

信頼の起点であるルート証明書

先程の「Example CA Root X1」はルート証明書※と呼ばれ、閲覧しているPCやブラウザの中にファイルが保存されています。

• ※PC出荷時からインストールされており、Windows Update等で更新されます。

ルート証明書は、実際のファイルがPCに保存されているということで信頼の起点となり、これをトラストアンカーと呼びます。アンカーとは、船を固定する「碇（いかり）」や「信頼のよりどころ」という意味です。

ルート証明書が保管される場所は、証明書ストア、ルートストア、ルートトラストストアなどと呼ばれており、多くの場合はWindowsやMac OSなどのOS単位で存在し、ブラウザはOSにインストールされたルート証明書を利用します。ただし、ブラウザの中でもMozilla Firefoxは独自の証明書ストアを持っているため、OSにインストールされた証明書を利用しません。そのため、「Chromeでは閲覧できるのにFirefoxではSSLのエラーが表示されて閲覧できない！」といったサイトが稀に存在することがあります。

ルート証明書はPCに保存されているという性質上、削除や更新、追加が非常に難しいことが特徴です。Let's Encryptのルート証明書に関する記事でもご紹介していますが、サポート期間の終わった古いOSなどではアップデートが提供されず、ルート証明書の追加ができないため、結果的にサーバー証明書が利用できない（そのサーバー証明書を使ったサイトが閲覧できない）という事態が発生します。

過去にはルート証明書の秘密鍵が認証局から流出するインシデントが発生し、Windows Updateなどでルート証明書が削除されたこともありました。重大かつ大規模な問題の場合、OSのサポートが切れていても例外的にWindows Updateなどが実施されることもあります。

ルート証明書は「信頼の起点」であるため、別の証明書によって署名されておらず、ルート認証局による自己署名となっています。一般的に証明書とは、運転免許証のように「正当な手続きを経たので、公安委員会はあなたが運転できることを認めます」と第三者が署名するものですが、自己署名とは「自分は運転が上手いから運転できることを認める！」と自身で署名するものです。そのため、企業がルート認証局となって、証明書ストアにルート証明書を入れてもらうためには相応の審査や手続きが必要となります。

また、ルート証明書の有効期間はPCなどのハードウェアのライフサイクルと紐付くため、非常に長いことが特徴です。例えば、最近利用が開始されたLet's Encryptのルート証明書「ISRG Root X1」は2035年まで利用できます。

失効リスクの分散に必要な中間CA証明書

「Example CA intermediate G2」と例示しているのが中間CA証明書（中間証明書）と呼ばれるものであり、通常は1～2つ設定されています。例のように「example.jp」というドメインを利用してサイトを公開している場合、そのサーバー内に中間CA証明書が保管されています。

中間CA証明書は、認証局のホームページから誰でもダウンロードできるような公開情報であり、「この期間に発行されたサーバー証明書には、この中間CA証明書を利用してください」といった説明文と共に掲載されています。

さて、なぜSSL証明書には公開情報である中間CA証明書が必要なのでしょうか？そもそも技術的には、ルート証明書の秘密鍵でサーバー証明書に直接署名することが可能です。前述の通り、ルート証明書はPCなどに直接ファイルとして保存されており、更新や削除が非常に難しくなっています。もし、ルート証明書で署名されたサーバー証明書を大量に失効する必要があった場合、無数にあるPCやスマートフォンからルート証明書を削除するか、大量のサーバー証明書を1つ1つ失効処理しなければなりません。ルート証明書は有効期間が非常に長いため、時間が経つにつれて署名されるサーバー証明書の数が膨大になり、このような失効処理時の影響が大きくなります。

そのような影響拡大を抑えるため、間に中間CA証明書を挟んでサーバー証明書に署名する階層構造を構成し、ルート証明書よりも有効期間を短く^※することでルート証明書を直接削除・失効するリスクを分散しています。これが中間CA証明書の目的です。

• ※2020年12月に発行されたLet's Encryptの中間CA証明書「R3」は2025年までの有効期間（約5年）です。

「証明書で署名する」という手続きを行う場合、秘密鍵を使用する必要がありますが、ルート証明書の秘密鍵はセキュリティ上の理由から容易にアクセスできるような場所には置くことができません。現在、先程のようなルート証明書でサーバー証明書を直接署名して発行することは認められておらず、認証局でこのような運用が行われているケースはありません。

また、中間CA証明書のメリットとして、ルート認証局がビジネスパートナーやクライアントの中間認証局に中間CA証明書を発行することで、ルート認証局ではない会社や団体がサーバー証明書を発行する機能を持つことができます。

上記の例のように、1つのルート証明書から、別々の会社へ中間CA証明書を発行することができます。これにより、例えば当社がルート認証局にならずとも、当社でドメイン認証などを行ってSSL証明書を販売することができます。もし、同じルート証明書を使うExample inc.という会社が固有のセキュリティインシデントを起こしたとしても、中間CA証明書が分かれているため、当社が発行したサーバー証明書を失効する必要はありません。

• ※インシデントのレベルによっては全ての中間CA証明書を失効する必要があるケースもあります。

サーバー証明書の設定時に、よく忘れられてしまうのも中間CA証明書の特徴です。発行されたサーバー証明書だけを設定してしまうミスが多く、さらにブラウザ側が自動的に中間CA証明書をダウンロードしてフォローしてくれる場合もあるため、設定忘れに気づきにくくなっています。サーバー管理者の方が中間CA証明書を設定しなくていい場合は、かなりレアケース…と言うよりほとんどありませんので設定するようにしましょう。SSL証明書の設定後は、認証局が提供するSSL設定チェッカーなどを利用して設定が正しいか確認することをおすすめします。

ドメインを保証するサーバー証明書

サーバー証明書は、エンドエンティティ証明書などとも呼ばれ、特定のドメイン名が記載されたサーバー証明書を使っているサーバーと通信していることを保証します。一般的に「SSL証明書を購入する」という行為はこのサーバー証明書を認証局から発行してもらうことを指します。

よく誤解されますが、サーバー証明書はドメインと通信先のサーバーが一致することを担保するものであり、サイト内容の合法性などを担保するものではありません。つまり、example.jp のページを表示していることは保証されますが、ページ内容がフィッシング詐欺であったとしてもサーバー証明書は関知しません。そのため、「アドレスバーに鍵マークがついていれば、そのサイトは安全！」というのは間違った認識です。

SSL証明書には組織認証を行うものも存在します。ドメインと通信先のサーバー、さらにそのサイトを運営している会社名・会社の実在性まで保証することができます。しかしながら、もしその会社がフィッシング詐欺サイトをサーバーに入れてしまえば、最も厳格なEV証明書を使ったサイトであったとしても不正なコンテンツを配信することが可能です。また、サーバーの管理者権限が乗っ取られてしまい悪意のある第三者が不正なコンテンツを配信する可能性もあります。

• ※このあたりはいくつかあるSSL証明書の限界の一つです。

ルート証明書にとって秘密鍵がとても大事なものであるのと同様に、サーバー証明書にとってCSRを作成する際に作った秘密鍵は大事なものです。これが流出すると、第三者がドメインを偽装する（例えば当サイトのssl.sakura.ad.jpを偽装する）ことができてしまいます。また、秘密鍵を紛失してしまうとサーバー証明書が利用できなくなってしまいます。

SSL証明書は最も有効期間が短く、現在では最長397日（約1年1ヶ月）とされています。

特性や弱点を知っておこう

このように、ルート証明書が中間CA証明書を認証し、中間CA証明書がサーバー証明書を認証することで、信頼の起点であるルート証明書がドメインの正当性を保証しています。裏を返せば、不正なルート証明書をPCにインストールすることでこの信頼の連鎖は簡単に壊れてしまい、ドメインの偽装や暗号の解読が可能になってしまいます。

• ※もちろん、ルート証明書をインストールするだけでこのような悪意のある攻撃が可能になるわけではありません。

悪用しているわけではありませんが、ウィルス対策ソフトの中にはPCにルート証明書をインストールし、通信内容を復号して不正な通信が行われていないか検査するものもあります。つまり、ルート証明書がインストールできればSSLの暗号化通信が簡単に破られてしまうのです。ウィルス対策ソフトを利用する際は、十分信頼できるものであることを認識したうえで利用しましょう。

SSL証明書は階層構造を構成することで、適度に利便性を担保しつつ共通理解が得られるほど安全にドメインを保証することができています。それぞれのSSL証明書の役割を知ることで、設定やセキュリティで気をつけることのポイントを理解し、SSL証明書選びなどに役立てていきましょう！

こちらの記事もあわせておすすめ！

SSL全体の概要については『SSLって何？意味や仕組みをわかりやすく解説！』、『SSL証明書の必要性 』などの記事がおすすめです。ウィルス対策ソフトがルート証明書をインストールすることについては『ウィルス対策ソフトなどのURLフィルタリング機能とSSL証明書について』で詳しく解説しています。