「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次  †
概要  †
- 「デジタル署名」の検証は、「送信側の公開鍵」を拠り所にしていると言えるが、提供される「送信側の公開鍵」の出所が、正規の出所か、検証できない(場合がある)という問題がある。
 
- このため、この問題を解決するための、「認証局」と呼ばれる、信頼のおける第三者が発行した「デジタル証明書」を使用して「送信側の公開鍵」が信頼できるものであるかを検証する機構がある。
 
- 「デジタル証明書」は、このような方式により成り立っているので、その信頼性は「認証局」の信頼性に依存する。
 
デジタル証明書  †
「デジタル証明書」は
- 「公開鍵が誰の公開鍵であるか?」を証明しているもので、
 
- 署名付きのメッセージと公開鍵を格納してある。
 
- 従って、証明書 = 署名付き公開鍵と言っても良い。
 
ファイル構造  †
- X.509という規格で決まっているため、X.509証明書とも呼ぶ。
 
- X.509の第1版は、1988年7月3日にX.500標準と関連して公開された。
 
- X.500標準と関連するため、DN(識別名)のルールなどはX.500を踏襲している。
 
認証局の自己(発行)証明書、送信側の証明書  †
この「デジタル証明書」には以下のものがある。
- 送信側の証明書
- pfx形式の電子証明書
 
- 送信側が認証局に証明書発行要求(CSR:Certificate Signing Request)によって発行してもらったもの。
 
 
デジタル証明書に含まれる情報  †
これらの「デジタル証明書」には、以下の情報が含まれる。
- (認証局がクライアントPCの証明書ストア(リポジトリ)に事前配布している)「認証局の自己(発行)証明書」
- 「認証局のメッセージ( + 認証局の公開鍵)」(公開鍵と、公開鍵の情報)
 
- 「認証局によるデジタル署名」(本証明書のコンテンツを検証するための署名)
 
 
- (送信側のCSR依頼によって認証局が送信側に発行した)「送信側の証明書」
- 「送信側の秘密鍵」(メッセージの署名に使用する)
 
- 「送信側のメッセージ( + 送信側の公開鍵)」(公開鍵と、公開鍵の情報)
 
- 「認証局によるデジタル署名」(本証明書のコンテンツを検証するための署名)
 
 
- 証明書におけるメッセージとは、CSRに格納される、発行者や有効期限などの情報を指す。
 
詳しくは、以下のページが参考になる。
デジタル証明書の発行  †
- 送信側が認証局にCSRを依頼して発行して「送信側の証明書」を発行もらう。
 
- 「認証局の自己(発行)証明書」は通常、事前にクライアントPCの証明書ストア(リポジトリ)に配布されている。
 
- このため、送信側・受信側は、「認証局の自己(発行)証明書」中の「認証局の公開鍵」を使用して、「送信側の証明書」を検証できる。
 
- ここでは送信側は、「送信側の証明書」(に含まれる「送信側のメッセージ・公開鍵」)が「認証局」により、
- 信頼できるものであるとされていることが確認でき、
 
- 以降、受信側が、送信側のメッセージ・署名を(安全に)検証できる。
 
 
デジタル証明書の利用  †
以下は、デジタル証明書を使用した送信側と受信側の通信。
- 送信側
- 受信側に「送信側の証明書」を送付する。
 
- 「送信側の秘密鍵」を使用してメッセージに署名を付与する。
 
- 「メッセージ+署名」を受信側に送付する。
 
 
- 受信側
送信側の公開鍵を使用して、「送信側のメッセージ+署名」を検証する。
- 証明書の検証
「認証局の公開鍵」を使用して「送信側の証明書」を検証する。 
- メッセージの検証
「送信側の公開鍵」を使用して、「送信側のメッセージ+署名」を検証する。 
 
秘密鍵付きの証明書の受け渡し  †
他者(上記、上記の図の場合、受信側に該当する)に証明書を渡す場合は、秘密鍵は渡されない。
秘密鍵付きの証明書の受け渡しは、pfxファイルのエクスポート・インポートなどで行なう。
ルートの認証局と中間の認証局  †
なお、「認証局」が「ルートの認証局」と「中間の認証局」に分かれる場合は、次のようになる。
- 「ルートの認証局の自己(発行)証明書」(ルート証明書):
「ルートの認証局のメッセージ(+ルート認証局の公開鍵)」、「ルートの認証局によるデジタル署名」 
↓ 証明書の発行 & ↑ 検証
- 「中間の認証局の自己(発行)証明書」:
「中間の認証局のメッセージ(+中間の認証局の公開鍵)」、「ルートの認証局によるデジタル署名」 
↓ 証明書の発行 & ↑ 検証
- 「送信側の証明書」:
「送信側のメッセージ(+送信側の公開鍵)」、「中間の認証局によるデジタル署名」 
検証するとき、証明書チェーンを辿る等と表現するように、実際に、
「送信側の証明書」から「ルートの認証局の自己(発行)証明書」(ルート証明書)の証明書を辿るような動きをする。
証明書の種類  †
「デジタル証明書」の主要な利用例として、
サーバー証明書  †
シマンテック製品で言う所の「シマンテック セキュア・サーバ ID」
目的  †
サーバーのユーザが、サーバーの提供者の正当性を検証できるよう、
サーバーに「サーバー証明書」を埋め込む。
用途  †
以下で利用されている。
SSL暗号化通信  †
また、SSLは、「ハイブリッド・暗号化」を使用しているが、
このうちの「公開鍵・暗号化方式」で使用する鍵に「SSLサーバ証明書」に同梱されている秘密鍵・公開鍵を使用している。
証明書のランク  †
- DV(Domain Validation)
 
- OV(Organization Validation)
 
- EV(Extended Validation)
 
のランクがある。
詳しくは、下記を参照。
クライアント証明書(メール証明)  †
シマンテック製品で言う所の
- 「個人用電子証明書」
 
- 「シマンテック セキュアメール ID」
 
目的  †
ユーザーが別のユーザーの正当性を検証できるよう、
ユーザのメッセージに「クライアント証明書」を埋め込む。
用途  †
以下で利用されている。
- 電子メールメッセージ
 
- Webサービス(HTTPS)
 
ソフトウェア証明書  †
シマンテック製品で言う所の「コードサイニング証明書」
目的  †
プログラム配布先のユーザが、プログラムの開発元の正当性を検証できるよう、
開発したソフトウェアの実行モジュールに「コードサイニング証明書」を埋め込む。
用途  †
拡張子から判断(*.cer, *.pfx, etc.)  †
証明書発行要求(CSR)  †
- *.csrファイルは証明書発行要求(CSR:Certificate Signing Request)を格納したファイル。
 
- 「—–BEGIN CERTIFICATE REQUEST—–」から始まり、「—–END CERTIFICATE REQUEST—–」で終わる。
 
cer, cet形式の電子証明書  †
- *.cerファイルはマイクロソフトが使っている拡張子の取り決めで、*.cetファイルと同じ。
 
- "cer"はcertificateの意味で、主に自己(発行)証明書(ルート証明書)のインポートで使用する。
 
- 「—–BEGIN CERTIFICATE —–」から始まり、「—–END CERTIFICATE—–」で終わる。
 
- 一般的な証明書は、この形式で証明書の所有者情報や公開鍵を含む。
 
- *.cerファイルは、*.pfxファイルや*.spcファイルに含まれることもある。
 
spc形式の電子証明書  †
- *.spcファイルはマイクロソフトが使っている拡張子の取り決めで、*.p7bファイルと同じPKCS #7形式。
 
- 証明書本体の他に、証明機関の証明書も一つのファイルに一緒に含めたい場合に利用する。
 
- ソフトウェア発行元証明書とも呼ばれ、署名を行う際に利用される。
 
pvk形式の秘密鍵  †
- *.pvkファイルはマイクロソフトが使っている拡張子の取り決めで、*.keyファイルと同じ形式。
 
- 「—–BEGIN RSA PRIVATE KEY—–」から始まり、「—–END RSA PRIVATE KEY—–」で終わる。
 
pfx形式の電子証明書  †
- *.pfxファイルはマイクロソフトが使っている拡張子の取り決めで、*.p12ファイルと同じPKCS #12形式。
 
- *.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 
- X.509形式の証明書が複数パッケージされた形式
 
- 中間証明書を含めて配布ができるのが大きな特徴
 
PKCS #12  †
- 名称
Personal Information Exchange Syntax Standard 
証明書生成の方法  †
IISを使用して「証明書チェーンがない自己(署名)証明書」を生成できる。
証明書サービス (AD CS)を使用して「証明書チェーンがある自己(署名)証明書」を生成できる。
EXE(ツール)  †
Windows SDK (旧Platform SDK)に同梱されているツール。
Makecert.exe  †
- Makecert.exe (証明書作成ツール)
 
- デジタル署名用の公開キーと秘密キーのペアを作成し、証明書ファイルの中に格納する。
 
Pvk2Pfx.exe  †
*.cer、*.spc、*.pvk の各ファイルに格納されている公開キーと秘密キーの情報を*.pfx ファイルにコピーするコマンド
Cert2spc.exe  †
OpenSSL  †
- 中身をダンプできるので、これを使ってデバッグできる。
 
- これにより、X509Certificate、X509Certificate2等の問題を切り分けられる。
 
- 例
- *.pfx を *.cer に変換し、*.cer からpublickeyを取得する方法
- openssl pkcs12 -in XXX.pfx -out XXX.cer -nokeys -clcerts
Enter Import Password: 
- openssl x509 -inform PEM -in XXX.cer -pubkey -noout > publicKey.key
 
 
 
- privateKeyを生成して、*.cerと結合して*.pfx を生成するという方法はダメっぽい。
- 元の秘密鍵(キーペア)と結合するしかダメっぽい。
 
- 新規作成した秘密鍵と結合しようとすると「No certificate matches private key」と怒られる。
 
- また、当然、公開鍵から秘密鍵を生成することなんて出来ないし。
- openssl genrsa > privateKey.key
 
- openssl pkcs12 -in XXX.crt -inkey privateKey.key -export -out YYY.pfx
 
 
 
- openssl genrsa > privatekey.key
 
- openssl pkcs12 -in XXX.crt -inkey privatekey.key -export -out YYY.pfx
 
- SSL サーバ証明書:DigiCert?(デジサート)
 
ライブラリ(DLL)  †
X509Certificate、X509Certificate2  †
- なんとなく、X509Certificate、X509Certificate2は、
- 署名の検証が厳しくてエラーになる事が多いのかもしれない。
 
- また、Windowsの証明書ストア(リポジトリ)と密結合しているため、難しさがある。
 
 
- PCLで使える。
 
- X509Certificate、X509Certificate2の代替として利用可能。
 
- C#での証明書操作には、BouncyCastleを使用しているケースが多い。
 
証明書ストア(リポジトリ)  †
アプリケーションによっては、
OSの証明書ストア(リポジトリ)以外に
専用のリポジトリを持っているものもある。
ツール  †
Certmgr.exe  †
- Certmgr.exe (証明書マネージャー ツール)
 
- CUIツール
 
Certmgr.msc  †
- Certmgr.msc (MMC 証明書スナップイン)
 
- GUIツール
 
論理証明書ストア  †
個人  †
- 管理するユーザー、コンピューター、またはサービスに発行
 
- これらがアクセスできる秘密キーに関連付けられている証明書。
 
信頼されたルート証明機関  †
- 暗黙的に信頼された「認証局の自己(発行)証明書」。
 
- グループ・ポリシーを使って信頼されたルート証明書を組織に配布できる。
 
中間証明機関  †
- 下位 認証局 に発行する「認証局の自己(発行)証明書」。
 
- グループ・ポリシーを使って中間証明機関を組織に配布できる。
 
エンタープライズの信頼  †
- 証明書信頼リストのコンテナ
 
- 他の組織の自己署名されたルート証明書を信頼する。
 
- 証明書を信頼する目的を制限するための機構を提供します。?
 
その他  †
- 信頼されたユーザー
 
- ほかの人
 
- 信頼された発行元
 
- サード パーティ ルート証明機関
 
- 証明書の登録要求
 
- 信頼されていない証明書
 
- Active Directory ユーザー オブジェクト
 
目的別ストア  †
サーバー認証  †
サーバー証明書
クライアント認証  †
クライアント証明書
コード署名  †
ソフトウェア証明書
セキュリティで保護された電子メール  †
メール証明
暗号化ファイル システム  †
FS によってデータの暗号化および暗号化の解除に使用される対称キーを
暗号化および暗号化解除するキーの組に関連付けられた証明書。
ファイル回復  †
EFS によって暗号化されたデータの回復に使用される対称キーを
暗号化および暗号化解除するキーの組に関連付けられた証明書。
表示  †
以下の手順で、目的別 or 論理ストア別に表示できる。
- 証明書スナップイン(Certmgr.msc)を開く。
 
- コンソール ツリーで、
- [証明書 - 現在のユーザー]
 
- or [証明書 (ローカル コンピューター)]
 
- or [証明書 - サービス]
 
 
をクリック。
- [表示] メニューの [オプション] をクリックし、
 
論理証明書ストア別  †
- [表示モードの分類] の [論理証明書ストア] をクリックし、[OK] をクリック。
 
- [論理ストア名] という列見出しが、詳細ウィンドウに表示される。
 
目的別  †
- [表示モードの分類] の [証明書の目的] をクリックし、[OK] をクリック。
 
- [目的] という列見出しが、詳細ウィンドウに表示される。
 
自己証明書  †
自己証明書には、以下の2種類の証明書がある。
自己(発行)証明書  †
- 行者と主体者が同一実体であるような公開鍵証明書。
 
- RFC 5280の3.2節などに定義が見える。
 
- 自己(発行)証明書には、以下の2種類の証明書がある。
 
自己(署名)証明書  †
「SSL等のPKIにおいてクライアント側で検証できない(認証パスを辿れない)サーバ証明書。」
全般のことを言い、正規の認証局から取得していない証明書全般を指す。
自己(署名)証明書には以下の様な種類がある。
証明書チェーンがない自己(署名)証明書  †
このタイプの自己(署名)証明書は証明書チェーンが無いため、
自身の秘密鍵をエクスポートして、クライアントにインポートさせる必要がある。
証明書チェーンがある自己(署名)証明書  †
企業内で独自認証局を運用しており、
独自認証局から発行した自己(署名)証明書は証明書チェーンを持っている。
- タイプ1
クライアントは独自認証局(ルートCA、中間CA)の証明書の公開鍵をインポートする。 
参考  †
内部リンク  †
外部リンク  †
証明書  †
Tags: :セキュリティ, :暗号化, :証明書