前提知識
デジタル証明書 (電子証明書) の理解のためにはまず RSA 公開鍵・秘密鍵について知る必要があります。
簡単に言うと以下がポイントになります。
- 公開鍵で暗号化すると、秘密鍵でしか復号できない (公開鍵では復号できない)
- 秘密鍵で暗号化すると、公開鍵でしか復号できない (秘密鍵では復号できない)
- 秘密鍵はサーバ等の特定機器のみに保持しておき、公開鍵は皆に見せる
- クライアントは公開鍵で暗号化することで、特定機器のみに復号できる情報を送ることができる
- サーバは通信で送るデータをハッシュ計算し、それを秘密鍵で暗号化する (これをデジタル署名と言う)。そしてクライアントにはデータとデジタル署名の 2 つを同時に送り、クライアントはデータのハッシュ計算をした結果とデジタル署名を公開鍵で復号した結果が一致するかを確認 (これを署名の検証と言う) する。一致すれば (相手は唯一秘密鍵を持っているはずなので)『相手はなりすましをしていないし、データも改ざんされていない』と判断できる (データは暗号化されないのでパケットキャプチャで盗聴されたら中身を見られる)
秘密鍵が外部に漏れてしまうと 4, 5 の前提が崩れるので役に立たなくなります。
以下のページで図解付きで易しく解説していますので併せてご参照下さい。
デジタル(SSL)証明書とは
デジタル証明書とは、あるサーバや NW 機器へ高セキュリティで通信するために使われる電子ファイルのことです。デジタル証明書は "認証局" と呼ばれる機能を持つサーバが生成します。
一番馴染みがあるのは http と併用する https (http oves SSL/TLS) での利用で、このときは SSL 証明書とも呼ばれます。
例えば『abc.example.com』というホスト名の Web サーバにデジタル証明書をインストールすると、https が使えるようになります。
そのためにはまず、"認証局 A" から『サーバ abc 用のデジタル証明書』を生成してもらう必要があります。
そのサーバ abc 用のデジタル証明書には『サブジェクト代替名 (DNS name)：abc.example.com』と記載されています。
デジタル証明書には公開鍵が含まれており、サーバにインストールする際は一緒に秘密鍵をインストールします。証明書 (公開鍵含む) はクライアントに公開しますが秘密鍵は誰にも見せません。
クライアントがサーバ abc に https でアクセスする際にはまずブラウザの URL 欄に『https://abc.example.com』と入力します。
次にブラウザは DNS サーバに abc.example.com の IP アドレスを聞きに行き、回答をもらいます。そしてブラウザはその IP アドレスに TCP コネクションを確立し、さらにその直後に SSL/TLS によるセキュア通信をするためのネゴシエーションを開始します。
デジタル証明書はこの SSL/TLS セッションのネゴシエーション最中に提示されます。
クライアントは提示された証明書のサブジェクト代替名 (SANs) と、ブラウザに入力した URL の FQDN (『https://』と『次の/』の間の文字列) が一致するかどうかを確認します。
これが一致した場合、かつ証明書自体が信頼できると判断された場合に、『その証明書の内容は正しい』と認識されます。
ただし、これだけでは足りません。デジタル証明書は一般にインターネット上に公開されるため、誰でも取得できるからです。
通信の暗号化をするための共通鍵の交換は Diffie-Hellman (DH) 系の方式が使われますが、DH 公開鍵を abc の秘密鍵で署名することで、『このサーバは間違いなく abc.example.com だ』と認識 (サーバを認証) することができます。
Diffie-Hellman の仕組みについては以下をご参照下さい。
デジタル証明書の用途
今回の例ではデジタル証明書 = SSL 証明書となっていますが、より厳密には、デジタル証明書の種類の 1 つとして SSL 証明書があります。
つまりデジタル証明書の用途は SSL/TLS に限られません。
IPsec 認証用やメール送信元の証明、EFS 暗号化 (個人単位でファイルを暗号化する Windows 標準機能) 等、様々な用途があります。
また、サーバ証明書とも呼ばれたりしますが、デジタル証明書はサーバ証明書に限らず、クライアント証明書としての使われ方もします。
色々と複雑なデジタル証明書ですが、次の説明では先程の話で出てきた『証明書自体が信頼できるかどうかをどのように判断するか』を説明していきます。
ルート証明書とは？
デジタル証明書の信頼モデルに関しては、よく役所の「印鑑証明」に例えられます。
以下に比較とイメージ図を示します。
デジタル証明書を発行する中間認証局が、その中間認証局の秘密鍵でデジタル証明書にデジタル署名します。これにより、デジタル証明書に書かれたホスト名の機器は、中間認証局がお墨付きをくれた状態になります。(印鑑証明で言う地方役所)
じゃあ中間認証局の身元は誰が保証するの？というと、更に上位の認証局です。
このプロセスを最上位であるルート認証局まで繰り返しますが、ルート認証局の身元は誰が保証するの？というと、自分自身でサインします。これは自己署名証明書と呼ばれます (俗に言うオレオレ証明書)。(印鑑証明で言う日本国)
そしてどのルート証明書を信頼すべきかは、OS やブラウザにあらかじめインストールされています。これはユーザ自身が付け加えることもできます (社内発行の認証局がある場合はよく行うやり方です)。
なお、メールの暗号化や認証を行う技術として OpenPGP や S/MIME がありますが、S/MIME は同じやり方で信頼性の担保をしています。
一方、OpenPGP は「信頼の輪 (Web of Trust)」≒「友達の友達は友達」という考え方で身元を保証しています。詳細は以下をご参照下さい。TLS との比較も行っています。
一般的な発行手順
デジタル証明書の一般的な発行手順は以下の通りです。
- Linux サーバの OpenSSL (もしくはその他の機器) の証明書発行コマンド等で、発行者情報等を入力し実行すると、CSR と秘密鍵が発行されます。(CSR の詳細については後述します。)
- 秘密鍵は他人に極力知られないようにしておき、CSR は認証局にメール等で送付します。(デジタル証明書本体は、インターネットに公開して使うのが一般的であり、その元となる CSR は公開されても構わない情報になります。)
- 認証局が自身の秘密鍵を使って、CSR に電子署名を付与します。その結果が「デジタル証明書」になります。このデジタル証明書を CSR 送信者へ送り返します。
- 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 サーバの安全性をよりアピールすることができます。さらにグリーンバーには運営組織が表示されます。
IT/インフラエンジニアの地位とスキル向上のために
あなたが成長の日々を歩めますように。
コメント
分かりやすい解説ありがとうございます。
1点だけ質問させてください。
ブラウザでWebサーバにアクセスする場合、TLSセッションの中でサーバ証明書がサーバからクライアントに渡される、とあります。
サーバ証明書は、事前にクライアントで保存(例えばWindowsの証明書ストアにインポート)しておく必要があるとの認識ですが、TLSセッションで受け渡しが行われるのであれば、クライアント側に保存した証明書は何に使われるのでしょうか。
hirok さん、コメントありがとうございます。
> サーバ証明書は、事前にクライアントで保存(例えばWindowsの証明書ストアにインポート)しておく必要があるとの認識
サーバ証明書をインポートするのではなく、ルート証明書を「信頼されたルート証明機関」ストアにインポートします。サーバ証明書1つ1つを信頼していくとWebサーバの台数分の証明書を保存していかなければならず、現実的ではありません。
サーバ証明書の信頼チェーンを辿り、一番上のルート証明書が自身の「信頼されたルート証明機関」にインストールされていれば、そのサーバ証明書自体が信頼できる、と判断するわけです。
なお、中間証明書はインストールしておく、というのも可能ではありますがそれもやはり大変なので、記事に記載の通り、サーバ証明書と一緒にバンドルするのが常套策です。
nesuke様、
早速の回答ありがとうございました。
自己証明書の場合、ルート証明書は以下コマンドで作成すると思います。
keytool -exportcert -keystore …
このルート証明書と上記で言うサーバ証明書とは同じものですか、異なるものですか。
記事にも書いていますが、ルート証明書であれば必ず自己署名証明書です。
自己署名証明書をサーバにインストールすればルート証明書＝サーバ証明書です。
回答いただき、ありがとうございました。
とても勉強になりました。
解説有難う御座います。1点質問させてください。
デジタル証明書に付加されるデジタル署名は何のデータを基に作成されているのか知りたいと思っています。
“CSRとは”というAgendaにおいて下記記載をいただいております。
“CSR には公開鍵が含まれており、この CSR を中間認証局に送り、中間認証局の秘密鍵で生成した電子署名 (CSR をハッシュ化したものを秘密鍵で暗号化) を CSR の末尾に付け加えることでデジタル証明書が出来上がります。”
私の理解では、申請者からのCSRを基に中間認証局が発行したデジタル証明書をハッシュ化したものを中間認証局の秘密鍵で暗号化したものが当該デジタル証明書に付加されるデジタル署名である、と認識しています。
上記記事中の記載と私の理解は同じ意味合いなのか、それとも異なるのかご意見をいただけると嬉しいです。
shinsさん、コメントありがとうございます。
> 私の理解では、申請者からのCSRを基に中間認証局が発行したデジタル証明書をハッシュ化したものを中間認証局の秘密鍵で暗号化したものが当該デジタル証明書に付加されるデジタル署名である、と認識しています。
すみません、記載いただいた文を見ると、合っているような、ちょっと違うような。。と、どちらにもとれる文章と感じがしました。
CSRを基に、「CSRに記載された情報の一部(公開鍵など)」と「中間認証局が付与する情報」を組み合わせたものがデジタル証明書の母体になり、その母体をハッシュ化⇒中間認証局の秘密鍵で署名したものを、その母体に付加することでデジタル証明書が完成します。
CSR の詳細については以下 RFC 3章、4章あたりをご参照ください。
https://tex2e.github.io/rfc-translater/html/rfc2986.html
認証局がどの部分を署名するか、については言及されていませんが、以下のように記載されています。