Open棟梁Project - マイクロソフト系技術情報 Wiki
目次 †
概要 †
- 「デジタル署名」の検証は、「送信側の公開鍵」を拠り所にしていると言えるが、提供される「送信側の公開鍵」の出所が、正規の出所か、検証できない（場合がある）という問題がある。
- このため、この問題を解決するための、「認証局」と呼ばれる、信頼のおける第三者が発行した「デジタル証明書」を使用して「送信側の公開鍵」が信頼できるものであるかを検証する機構がある。
- 「デジタル証明書」は、このような方式により成り立っているので、その信頼性は「認証局」の信頼性に依存する。
デジタル証明書 †
「デジタル証明書」は
- 「公開鍵が誰の公開鍵であるか？」を証明しているもので、
- 署名付きのメッセージと公開鍵を格納してある。
- 従って、証明書 ＝ 署名付き公開鍵と言っても良い。
ファイル構造 †
X.509という規格で決まっているため、X.509証明書とも呼ぶ。
詳しくは、
認証局の自己証明書、送信側の証明書 †
この「デジタル証明書」には以下のものがある。
- 送信側の証明書
- pfx形式の電子証明書
- 送信側が認証局にCSR（証明書発行要求：Certificate Signing Request）依頼によって発行してもらったもの。
デジタル証明書に含まれる情報 †
これらの「デジタル証明書」には、以下の情報が含まれる。
- （認証局がクライアントPCの証明書ストア（リポジトリ）に事前配布している）「認証局の自己証明書」
- 「認証局のメッセージ（ ＋ 認証局の公開鍵）」（公開鍵と、公開鍵の情報）
- 「認証局によるデジタル署名」（本証明書のコンテンツを検証するための署名）
- （送信側のCSR依頼によって認証局が送信側に発行した）「送信側の証明書」
- 「送信側の秘密鍵」（メッセージの署名に使用する）
- 「送信側のメッセージ（ ＋ 送信側の公開鍵）」（公開鍵と、公開鍵の情報）
- 「認証局によるデジタル署名」（本証明書のコンテンツを検証するための署名）
- 証明書におけるメッセージとは、CSRに格納される、発行者や有効期限などの情報を指す。
デジタル証明書の発行 †
- 送信側が認証局にCSRを依頼して発行して「送信側の証明書」を発行もらう。
- 「認証局の自己証明書」は通常、事前にクライアントPCの証明書ストア（リポジトリ）に配布されている。
- このため、送信側・受信側は、「認証局の自己証明書」中の「認証局の公開鍵」を使用して、「送信側の証明書」を検証できる。
- ここでは送信側は、「送信側の証明書」（に含まれる「送信側のメッセージ・公開鍵」）が「認証局」により、
- 信頼できるものであるとされていることが確認でき、
- 以降、受信側が、送信側のメッセージ・署名を（安全に）検証できる。
デジタル証明書の利用 †
以下は、デジタル証明書を使用した送信側と受信側の通信。
- 送信側
- 受信側に「送信側の証明書」を送付する。
- 「送信側の秘密鍵」を使用してメッセージに署名を付与する。
- 「メッセージ＋署名」を受信側に送付する。
- 受信側
送信側の公開鍵を使用して、「送信側のメッセージ＋署名」を検証する。
- 証明書の検証
「認証局の公開鍵」を使用して「送信側の証明書」を検証する。
- メッセージの検証
「送信側の公開鍵」を使用して、「送信側のメッセージ＋署名」を検証する。
秘密鍵付きの証明書の受け渡し †
他者（上記、上記の図の場合、受信側に該当する）に証明書を渡す場合は、秘密鍵は渡されない。
秘密鍵付きの証明書の受け渡しは、pfxファイルのエクスポート・インポートなどで行なう。
ルートの認証局と中間の認証局 †
なお、「認証局」が「ルートの認証局」と「中間の認証局」に分かれる場合は、次のようになる。
- 「ルートの認証局の自己証明書」:
「ルートの認証局のメッセージ（＋ルート認証局の公開鍵）」、「ルートの認証局によるデジタル署名」
↓ 証明書の発行 ＆ ↑ 検証
- 「中間の認証局の自己証明書」:
「中間の認証局のメッセージ（＋中間の認証局の公開鍵）」、「ルートの認証局によるデジタル署名」
↓ 証明書の発行 ＆ ↑ 検証
- 「送信側の証明書」:
「送信側のメッセージ（＋送信側の公開鍵）」、「中間の認証局によるデジタル署名」
検証するとき、証明書チェーンを辿る等と表現するように、実際に、
「送信側の証明書」から「ルートの認証局の自己証明書」の証明書を辿るような動きをする。
証明書の種類 †
「デジタル証明書」の主要な利用例として、
サーバー証明書 †
ベリサイン製品で言う所の「ベリサインサーバID」
目的 †
サーバーのユーザが、サーバーの提供者の正当性を検証できるよう、
サーバーに「サーバー証明書」を埋め込む。
用途 †
以下で利用されている。
SSL暗号化通信 †
また、SSLは、「ハイブリッド・暗号化」を使用しているが、
このうちの「公開鍵・暗号化方式」で使用する鍵に「SSLサーバ証明書」に同梱されている秘密鍵・公開鍵を使用している。
クライアント証明書（メール証明） †
ベリサイン製品で言う所の
目的 †
ユーザーが別のユーザーの正当性を検証できるよう、
ユーザのメッセージに「クライアント証明書」を埋め込む。
用途 †
以下で利用されている。
- 電子メールメッセージ
- Webサービス（HTTPS）
ソフトウェア証明書 †
ベリサイン製品で言う所の「コードサイニング証明書」
目的 †
プログラム配布先のユーザが、プログラムの開発元の正当性を検証できるよう、
開発したソフトウェアの実行モジュールに「コードサイニング証明書」を埋め込む。
用途 †
拡張子から判断（*.cer, *.pfx, etc.） †
cer, cet形式の電子証明書 †
- "cer"はcertificateの意味で、主に自己証明書（ルート証明書）
- *.cerファイルはマイクロソフトが使っている拡張子の取り決めで、*.cetファイルと同じ。
- 一般的な証明書は、この形式で証明書の所有者情報や公開鍵を含む。
- *.cerファイルは、pfxファイルやspcファイルに含まれることもある。
spc形式の電子証明書 †
pvk形式の秘密鍵 †
- *.pvkファイルはマイクロソフトが使っている拡張子の取り決めで、*.keyファイルと同じ形式。
pfx形式の電子証明書 †
- *.pfxファイルのエクスポート・インポートには、パスワードが必要。
- *.pfxファイルのエクスポート・インポートは、次の手順に従う。
この一連の操作は、Windowsの証明書スナップインや、Pvk2Pfx.exeなどで確認できる。 [#b671995d]
- 秘密鍵付きの証明書をパスワードで暗号化して*.pfxファイルとしてエクスポートする。
- エクスポートした*.pfxファイルを渡す。
- *.pfxファイルをパスワードで復号化して秘密鍵付きの証明書をインポートする。
Encoding (*.derと, *.pem) †
鍵の中身ではなく、エンコーディングを表している。
- DER
- 鍵や証明書をASN.1というデータ構造の記述方法で表し、
- それをDERシリアライズしたバイナリファイル
- PEM
- 鍵や証明書をASN.1というデータ構造の記述方法で表し、
- それをBase64シリアライズしたバイナリファイル
- ファイルの先頭に -- BEGIN... という行があればPEM。
PKCS の種別 †
PKI で利用する証明書や秘密鍵などのフォーマットを定めた標準として、
PKCS (Public Key Cryptography Standard) が RSA Security 社によって策定。
PKCS #7 †
- 名称
Cryptographic Message Syntax Standard
- 説明
- RFC2315
- 暗号データやデジタル署名のフォーマット
- 証明書や CRL の配布、S/MIME にも利用
- X.509形式の証明書が複数パッケージされた形式
- 中間証明書を含めて配布ができるのが大きな特徴
PKCS #12 †
- 名称
Personal Information Exchange Syntax Standard
- 説明
- 秘密鍵と証明書を交換するためのフォーマット
- 秘密鍵はパスワードで保護される。
証明書生成の方法 †
IISを使用して「証明書チェーンがない自己署名証明書」を生成できる。
証明書サービス (AD CS)を使用して「証明書チェーンがある自己署名証明書」を生成できる。
Makecert.exe, Pvk2Pfx.exe †
Windows SDK (旧Platform SDK)に同梱されているツール。
Makecert.exe †
- Makecert.exe (証明書作成ツール)
- デジタル署名用の公開キーと秘密キーのペアを作成し、証明書ファイルの中に格納する。
Pvk2Pfx.exe †
*.cer、*.spc、*.pvk の各ファイルに格納されている公開キーと秘密キーの情報を*.pfx ファイルにコピーするコマンド
証明書ストア（リポジトリ） †
自己署名証明書 †
「SSL等のPKIにおいてクライアント側で検証できない(認証パスを辿れない)サーバ証明書。」
全般のことを言い、正規の認証局から取得していない証明書全般を指す。
自己署名証明書には以下の様な種類がある。
証明書チェーンがない自己署名証明書 †
このタイプの自己署名証明書は証明書チェーンが無いため、
自身の秘密鍵をエクスポートして、クライアントにインポートさせる必要がある。
証明書チェーンがある自己署名証明書 †
企業内で独自認証局を運用しており、
独自認証局から発行した自己署名証明書は証明書チェーンを持っている。
タイプ１ †
クライアントは独自認証局（ルートCA、中間CA）の証明書の公開鍵をインポートする。
タイプ２ †
この独自認証局が正規の認証局から、中間認証局の証明書を取得している場合、
この中間CA証明書、クロスルート設定用証明書がサーバ側に設定されていれば、
クライアント側の独自認証局の公開鍵のインポートは不要・・・だと思うが、
AD CSの場合はGPOで配布するのかもしれないので要確認。
参考 †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
