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

スポンサーリンク
スポンサーリンク

前提知識

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

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

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

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

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

【図解】初心者にもわかりやすい『公開鍵・秘密鍵』の仕組み 〜身近で具体的な利用例やメリット〜
【図解】初心者にもわかりやすい『公開鍵・秘密鍵』の仕組み 〜身近で具体的な利用例やメリット〜
公開鍵・秘密鍵でできること 特定のサーバAが秘密鍵を持ち、任意のクライアントが...

デジタル(電子)証明書とは

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

一番馴染みがあるのはhttpと併用するhttps(http oves SSL/TLS)での利用です。

例えば『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コネクションを確立し、さらにその直後に TLS によるセキュア通信をするためのネゴシエーションを開始します。

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

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

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

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

なので、共通鍵の暗号化をこの公開鍵・秘密鍵で行い、http通信の暗号化は比較的負荷の軽い共通鍵で行うのです。なお、httpsで伝わる情報は通常のhttpと差異は一切ありません。

今回の例ではデジタル証明書=SSL証明書となっていますが、より厳密には、デジタル証明書の種類の1つとしてSSL証明書があります。つまりデジタル証明書の用途はSSL/TLSに限られませんIPsec認証用や、WindowsのRDP認証用等、様々な用途があります。また、サーバ証明書とも呼ばれたりしますが、デジタル証明書はサーバ証明書に限らず、クライアント証明書としての使われ方もします。

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

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

デジタル証明書の信頼モデルに関しては、よく役所の「印鑑証明」に例えられます。以下に比較とイメージ図を示します。

スポンサーリンク

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

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

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

そしてどのルート証明書を信頼すべきかは、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による審査が、『サイトが正しいものである』という保証をする根拠になります

スポンサーリンク
スポンサーリンク
スポンサーリンク

シェアする

  • このエントリーをはてなブックマークに追加

フォローする

スポンサーリンク
スポンサーリンク