【図解】よく分かるデジタル証明書(SSL証明書)の仕組み 〜https通信フロー,発行手順,CSR,自己署名(オレオレ)証明書,ルート証明書,中間証明書の必要性や扱いについて〜

前提知識

デジタル証明書 (電子証明書) の理解のためにはまず公開鍵・秘密鍵について知る必要があります

簡単に言うと以下がポイントになります。

  1. 公開鍵で暗号化すると、秘密鍵でしか復号できない(公開鍵では復号できない)
  2. 秘密鍵で暗号化すると、公開鍵でしか復号できない(秘密鍵では復号できない)
  3. 秘密鍵はサーバ等の特定機器のみに保持しておき、公開鍵は皆に見せる
  4. クライアントは公開鍵で暗号化することで、特定機器のみに解読できる情報を送ることができる
  5. サーバは通信で送るデータをハッシュ計算し、それを秘密鍵で暗号化する(これをデジタル署名と言う)。そしてクライアントにはデータとデジタル署名の2つを同時に送り、クライアントはデータのハッシュ計算をした結果とデジタル署名を公開鍵で復号した結果が一致するかを確認する。一致すれば (相手は唯一秘密鍵を持っているはずなので)『相手はなりすましをしていないし、データも改ざんされていない』と判断できる(データは暗号化されないのでパケットキャプチャで盗聴されたら中身を見られる)

秘密鍵が外部に漏れてしまうと 4, 5 の前提が崩れるので役に立たなくなります。

以下のページで図解付きで易しく解説していますので併せてご参照下さい。

【図解】初心者も分かる"公開鍵/秘密鍵"の仕組み~公開鍵暗号方式の身近で具体的な利用例やメリット〜
【図解】初心者も分かる"公開鍵/秘密鍵"の仕組み~公開鍵暗号方式の身近で具体的な利用例やメリット〜
公開鍵・秘密鍵でできること ~暗号化とデジタル署名~ 特定のサーバ A が秘密...

デジタル(SSL)証明書とは

デジタル証明書とは、あるサーバや NW 機器へ高セキュリティで通信するために使われる電子ファイルのことです。デジタル証明書は "認証局" と呼ばれる機能を持つサーバが生成します

一番馴染みがあるのは http と併用する https (http oves SSL/TLS) での利用で、このときは SSL 証明書とも呼ばれます。

例えば『abc.example.com』というホスト名の Web サーバにデジタル証明書をインストールすると、https が使えるようになります。

そのためにはまず、"認証局 A" から『サーバ A 用のデジタル証明書』を生成してもらう必要があります。

そのサーバ A 用のデジタル証明書には『コモンネーム:abc.example.com』と記載されています。

デジタル証明書には公開鍵が含まれており、サーバにインストールする際は一緒に秘密鍵をインストールします。証明書 (公開鍵含む) はクライアントに公開しますが秘密鍵は誰にも見せません

クライアントがサーバ A に https でアクセスする際にはまずブラウザの URL 欄に『https://abc.example.com』と入力します。

次にブラウザは DNS サーバに abc.example.com の IP アドレスを聞きに行き、回答をもらいます。そしてブラウザはその IP アドレスに TCP コネクションを確立し、さらにその直後に SSL/TLS によるセキュア通信をするためのネゴシエーションを開始します。

デジタル証明書はこの SSL/TLS セッションのネゴシエーション最中に提示されます

クライアントは提示された証明書のコモンネームと、ブラウザに入力した URL の FQDN(『https://』と『次の/』の間の文字列)が一致するかどうかを確認します。

これが一致した場合、かつ証明書自体が信頼できると判断された場合に、『そのサーバは間違いなく abc.example.com だ』と認識(サーバを認証)することができます。

そして暗号化通信を行うための共通鍵を生成するために、その元となるネタを、公開鍵で暗号化してサーバへ送ります。

公開鍵・秘密鍵による暗号・復号はリアルタイムに生成するケースではとてもセキュアですが、その反面、CPU 負荷が高いです。

なので、共通鍵の暗号化をこの公開鍵・秘密鍵で行い、http 通信の暗号化は比較的負荷の軽い共通鍵で行うのです(※共通鍵の生成方法はこれ以外には Difiie-Hellman アルゴリズムによるものがあり、スノーデン事件以降は特に Difiie-Hellman が使われるようになり、さらには TLS v1.3 では公開鍵による交換は廃止になりました。)。なお、https で伝わる情報は通常の http と差異は一切ありません。

今回の例ではデジタル証明書 = SSL 証明書となっていますが、より厳密には、デジタル証明書の種類の 1 つとして SSL 証明書があります。

つまりデジタル証明書の用途は SSL/TLS に限られませんIPsec 認証用やメール送信元の証明、EFS 暗号化 (個人単位でファイルを暗号化する Windows 標準機能) 等、様々な用途があります。

また、サーバ証明書とも呼ばれたりしますが、デジタル証明書はサーバ証明書に限らず、クライアント証明書としての使われ方もします。

色々と複雑なデジタル証明書ですが、次の説明では先程の話で出てきた『証明書自体が信頼できるかどうかをどのように判断するか』を説明していきます。

デジタル証明書を信頼する条件

デジタル証明書の信頼モデルに関しては、よく役所の「印鑑証明」に例えられます。

以下に比較とイメージ図を示します。

デジタル証明書を発行する中間認証局が、その中間認証局の秘密鍵でデジタル証明書にデジタル署名します。これにより、デジタル証明書に書かれたホスト名の機器は、中間認証局がお墨付きをくれた状態になります。(印鑑証明で言う地方役所)

じゃあ中間認証局の身元は誰が保証するの?というと、更に上位の認証局です。

このプロセスを最上位であるルート認証局まで繰り返しますが、ルート認証局の身元は誰が保証するの?というと、自分自身でサインします。これは自己署名証明書と呼ばれます (俗に言うオレオレ証明書)。(印鑑証明で言う日本国)

そしてどのルート証明書を信頼すべきかは、OS やブラウザにあらかじめインストールされています。これはユーザ自身が付け加えることもできます (社内発行の認証局がある場合はよく行うやり方です)。

一般的な発行手順

デジタル証明書の一般的な発行手順は以下の通りです。

  1. Linux サーバの OpenSSL (もしくはその他の機器) の証明書発行コマンド等で、発行者情報や、デジタル証明書を利用したい機器のホスト名 (コモンネーム=FQDN) 等を入力し実行すると、CSR と秘密鍵が発行されます。CSR の詳細については後述します。
  2. 秘密鍵は他人に極力知られないようにしておき、CSR は認証局にメール等で送付します。(デジタル証明書本体は、インターネットに公開して使うのが一般的であり、その元となる CSR は公開されても構わない情報になります。)
  3. 認証局が自身の秘密鍵を使って、CSR に電子署名を付与します。その結果が「デジタル証明書」になりますこのデジタル証明書を CSR 送信者へ送り返します。
  4. CSR 送信者は秘密鍵とデジタル証明書をセットで、利用したい機器にインストールします。(CSR を発行した機器とは別でも構いません)

CSRとは

CSR とは証明書発行要求 (Certificate Signing Request) と呼ばれるもので、これを生成する際に、秘密鍵と公開鍵も作られます。

CSR には公開鍵が含まれており、この CSR を中間認証局に送り、中間認証局の秘密鍵で生成した電子署名 (CSR をハッシュ化したものを秘密鍵で暗号化) を CSR の末尾に付け加えることでデジタル証明書が出来上がります

デジタル証明書の検証

デジタル証明書の正当性を確認する人 (デジタル証明書を Web サーバにインストールした場合は、その Web サーバへアクセスする人) は、中間認証局の公開鍵を使って電子署名を復号化し、実際のデジタル証明書のハッシュ値を計算したものと比較し、同じであることを検証します。

中間証明書の正当性は同じようにルート認証局の公開鍵を利用して行います。

そして前述の通り、ルート認証局についてはあらかじめ、もしくは手動でインストールされているルート証明書が PC 内にあるかどうかを検証します。

中間証明書の必要性と、扱う上での注意点

信頼されたルート証明書は一度その秘密鍵が漏れてしまうと世界中のクライアントに影響が出てしまいます。その場合は速やかにそのルート証明書を失効し、新たな証明書を生成し、クライアントに配布する必要があります。

この作業は大変なので、ルート証明書の代わりに中間証明書を間に噛ませるのです。以下ページも併せてご参照下さい。

中間証明書の必要性、証明機関(認証局)の階層化の理由
中間証明書の必要性、証明機関(認証局)の階層化の理由
証明機関は階層構造を取ることができます。ツリー構造的に管理ができ、整理がしやすい...

中間証明書はルート証明書のように PC にあらかじめインストールされているものも多いですが、一般的に動的に作られやすい性質であるため、インストールされていないケースも頻繁に見られます。

なのでデジタル証明書をインストールする際には、中間証明書も一緒にインストールするのが一般的です。

一般的にはそのデジタル証明書と中間証明書をテキストエディタでのコピペ等を使って 1 つのファイルに連結し、そのデジタル証明書ファイルを、利用したい機器へインストールします。

そうすることで中間証明書の公開鍵によるデジタル証明書の検証が可能になります。

中間証明書は PC に含まれていないことが多く、このような連結操作をしてからインストールしないとルート証明書の検証まで辿り着かず、証明書エラーが表示されてしまうケースがあります

ルート証明書や中間証明書のPCへのインストール状況確認方法、およびインストール方法

先程の図の左側は Google のデジタル証明書を Windows で開いたもの、右側は中間証明書とデジタル証明書を base64 encoded X.509 で Export し、メモ帳で連結したものです。

Windows OS としては中間証明書を上、デジタル証明書を下に連結することで、中間証明書付のデジタル証明書として認識できます

ただし、ロードバランサなどメーカによってはデジタル証明書を上、中間証明書を下に連結しないとうまく認識しないことがあるので注意が必要です

中間証明書やルート証明書が Windows にインストールされているかどうかを確認するには、IE の「インターネットオプション」⇒「コンテンツ」⇒「証明書」から、[中間証明機関] (中間証明書の場合) や [信頼されたルート証明機関] (ルート証明書の場合) をクリックします。

上図にある『インポート』ボタンを使って、ダウンロードした中間証明書やルート証明書をインストールすることができます。

自己署名証明書について

デジタル証明書の規格の決まりでルート証明書にも電子署名は必要なので、前述の通り、ルート証明書は自分の秘密鍵を使って電子署名します。

なのでルート証明書は必ず、自己署名証明書 (俗に言うオレオレ証明書) となります

よく誤解されていますが、『自分で作った (ベリサイン等で発行されていない) デジタル証明書 = 自己署名証明書』ではありません

実際自分で自己署名証明書を作るケースは多いですが、異なるケースとして、例えば Windows サーバや Linux サーバ等で自分でルート認証局 (CA) を立てその CA の秘密鍵を使ってデジタル署名した証明書は、自己署名証明書とは呼びません

そのルート認証局のルート証明書をインストールしているクライアントにとっては問題のない証明書ですし、インストールされていないクライアントにとっては、単に公に信頼されていないデジタル証明書です。

秘密鍵について

秘密鍵は、必ずデジタル証明書とペアで使う必要があり、「秘密鍵を持っていること」が、「その電子証明書の内容の正当な持ち主」であることを証明し、また同時に、通信の暗号化を行うことができます。 なので秘密鍵は厳密に管理が必要で、もし秘密鍵が誰かにばれたら、その電子証明書は速やかに利用を止めるべきです。

また、その性質から、メールで送ることも極力避けるべきです。ましてやメーリングリスト等はもってのほかです。

認証局の例

認証局は自分で立てることもできますが、例えばインターネットに公開する Web サーバに使う場合、証明書エラーを出さずに使うためには世界中のクライアントにその認証局のルート証明書をインストールしてもらう必要があります

社内 PC だけならともかく世界中となると現実的ではありません。

そこでどうするかというと、もともと名のしれた認証局に有償で発行をお願いするのです(例えばジオトラストなど)。

条件や物によっては無償で発行できます。例えば最近では Let's Encrypt というのが話題になっています。本サイトでも 2018/3/31 から Let's Encrypt の証明書を導入しました。

認証局による認証

認証局の役割として、誰にでも好きな証明書を発行させてしまっては意味がなくなります

認証局は『申請者がその証明書を扱うに足る人物か』というのを調査します。

例えばあなたがyahohoho.co.jpというドメインを取得していたとして、www.yahohoho.co.jpというWebサイトをhttps化するために証明書を取得しようとします。

そして認証局に"www.yahohoho.co.jp"というホスト名の証明書の発行依頼を相談します。すると、認証局は、あなたがyahohoho.co.jpのドメインの所有者であることを色々な手段で確認します

例えば認証局からあなたへメールで秘密のパスワードを送り、あなたはそのパスワードを記載したファイルを、yahohoho.co.jpドメイン内のWebサイトの指定ディレクトリに配置し、認証局の人がそのファイルを確認する、といった審査をします。

このようなドメインの審査で問題なければ、お金を払うことによって証明書を発行してもらうことができます。このCAによる審査が、『サイトが正しいものである』という保証をする根拠になります

この認証局による認証をどれくらいしっかりと行うかによって、証明書の種類は3種類に分かれます。

1つ目は Let's Encrypt に代表される DV 証明書 (Domain Validation証明書) です。この証明書は、認証局の人は「対象ドメインを管理する権限があるか」ということのみを確認します。

2つ目は OV 証明書 (Organization Validation証明書) で、ドメインの管理権に加え、運営組織の実在性などを電話などにより確認します。

3つ目は EV 証明書 (Extended Validation証明書) で、OV 証明書と同様の確認を行いますが、確認方法が国際的な認定基準に基づいて行われます。それに加え、ブラウザのアドレスバーが緑色になる「グリーンバー」によりそのWebサーバの安全性をよりアピールすることができます。さらにグリーンバーには運営組織が表示されます。