デジタル証明書(SSL証明書)の仕組み、中間証明書の扱い

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

デジタル証明書とは

デジタル証明書とは、認証局(CA:Certificate Authrityの略。証明機関ともいう。例えばジオトラストなど)から有償(条件によっては無償)で発行してもらい、 それを機器(多くはWebサーバ)にインストールすることで、その機器へアクセスする利用者が 「この機器は正当なものだ(偽装されたものではない)」と認証しつつ、その機器と利用者の間で暗号化通信を実現するものです。つまり、認証暗号化の機能を提供します。用途はhttpsに限りません。

暗号化は、いわゆる非対称鍵(公開鍵/秘密鍵)と共通鍵を使うもので、イメージしやすいと思いますが、認証といっても何を持って正しいと判断するのかが分かりにくいと思いますので説明します。

例えばあなたがyahohoho.co.jpというドメインを取得していたとして、www.yahohoho.co.jpというWebサイトをhttps化するために証明書を取得しようとします。その場合は、認証局に発行依頼を相談します。すると、認証局は、あなたがyahohoho.co.jpのドメインの所有者であることを色々な手段で確認します

例えば認証局からあなたへメールで秘密のパスワードを送り、あなたはそのパスワードを記載したファイルを、yahohoho.co.jpのWebサイトのトップディレクトリに配置し、認証局の人がそのファイルを確認する、といった審査をします。その審査で問題なければ、お金を払うことによって証明書を発行してもらうことができます。このCAによる審査が、『サイトが正しいものである』という保証をする根拠になります

スポンサーリンク

デジタル証明書はSSL証明書と違いは無いと考えて良いです。が、より厳密には、デジタル証明書の種類の1つとしてSSL証明書があります。デジタル証明書の用途はSSL(今はSSLは使われていないので後継のTLS)に限られませんIPsec認証用や、WindowsのRDP認証用等、様々な用途があります。

また、デジタル証明書のことを、Windowsでは『セキュリティ証明書』と呼んでいます。

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

スポンサーリンク

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

  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サーバへアクセスする人)は、中間認証局の公開鍵を使って電子署名を復号化し、実際のデジタル証明書のハッシュ値を計算したものと比較し、同じであることを検証します。

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

しかし、ルート認証局の正当性は検証しようがありません。 なので信用するルート証明書をあらかじめ決めておき、設定しておく必要があります。例えばOSにはあらかじめ信頼すべきルート証明書がインストールされており、https通信で サーバ証明書を検証する際、最後にルート証明書にたどりつきますが、そのルート証明書が OSにセットされているか否かを確認します。このルート証明書は後から自身でOSにインストールすることもできます。

中間証明書の扱い

中間証明書については、一般的にはそのデジタル証明書と中間証明書を1つのファイルに連結し、そのデジタル証明書ファイルを、利用したい機器へインストールします。そうすることで中間証明書の公開鍵によるデジタル証明書の検証が可能になります。

スポンサーリンク

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

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

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

もし中間証明書を連結せず、デジタル証明書だけをインストールする場合は、利用者側のOSにインストールされている中間証明書を利用しますが、インストールされていなかったら検証に失敗し、エラーとなります。

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

ルート証明書→自己署名証明書

デジタル証明書の規格の決まりでルート証明書にも電子署名は必要なので、ルート証明書は自分の秘密鍵を使って電子署名します。 なのでルート証明書は必ず、自己署名証明書(俗に言うオレオレ証明書)となります

よく誤解されていますが、ベリサイン等で発行されていない、自分で作ったデジタル証明書=自己署名証明書ではありません。実際自分で自己署名証明書を作るケースは多いですが、異なるケースとして、例えばWindowsサーバやLinuxサーバ等で自分でルート認証局(CA)を立て、そのCAの秘密鍵を使って電子署名したデジタル証明書は、自己署名証明書とは呼びません。単に公に信頼されていないデジタル証明書です。(ただし、そのルート認証局のルート証明書を信頼するルート証明書にインストールすればローカルでは信頼されたデジタル証明書として扱えます)

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

電子証明書の利用方法は様々です。例えばWebサーバ(Windows ServerのIISやRedHat Enterprise LinuxのApacheなど)にインストールすれば「サーバ証明書」として機能し、https通信によりサーバの正当性主張および通信暗号化を 行うことができます。

この場合、サーバ管理者はジオトラストなどの認証局サービス業者にお金を払ってサーバ証明書を発行してもらい、 それをインストールする必要があります。

また、クライアント(WindowsやMacintoshなど)のブラウザにインストールすれば「クライアント証明書」として機能し、そのクライアントが「その証明書保有者のみが閲覧できるサイト」を閲覧することができます。

この場合、基本的には「証明書の発行元=そのサイト運営者」となります。

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

シェアする

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

フォローする

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