SSL Certificates HOWTO Franck Martin 原啓介 - 日本語訳 kshara@mars.dti.ne.jp Revision History Revision v0.5 2002-10-20 Revised by: FM Adding IPsec information from Nate Carlson, natecars@natecarlson.com / Adding IMAPS and POPS information from Bill Shirley, webnut@telocity.com / Adding WinCrypt information from Colin McKinnon, colin@wew.co.uk Revision v0.4 2002-06-22 Revised by: FM Various corrections - adding ASCII Art Revision v0.3 2002-05-09 Revised by: FM Adding x509v3 extension information - Correcting spelling Revision v0.2 2001-12-06 Revised by: FM Adding openssl.cnf file / Adding CRL info from Averroes, a.averroes@libertysurf.fr / Correcting spelling Revision v0.1 2001-11-18 Revised by: FM Creation of the HOWTO 認証局(CA, Certificate Authority)の運用の方法や、安全な Web 接続、 e-mail に用いるためにどう証明書を発行し、署名するか、または、署名入りコ ードの作り方、その他の使い方についての、最初の入門的解説。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Table of Contents 1. 一般的知識 1.1. イントロダクション 1.2. SSL とは何か、証明書とは何か？ 1.3. S/MIME その他のプロトコルってどんなもの？ 2. 証明書の運用 2.1. インストール 2.2. ルート認証局証明書を作る 2.3. 非ルート認証局証明書を作る 2.4. 信用が与えられたルート証明書として CA ルート証明書をインストー ルする 2.5. 証明書の運用 3. アプリケーションで証明書を使う 3.1. セキュアなインターネットプロトコル 3.2. メイルをセキュアに 3.3. ファイルシステムをセキュアに 3.4. コード（プログラム）をセキュアに 3.5. IPSec 4. グローバル PKI 4.1. 現在の PKI の状況 4.2. グローバル PKI の必要性 5. 日本語版謝辞 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Chapter 1. 一般的知識 1.1. イントロダクション 親愛なる読者諸氏、私と同じように OpenSSL プロ ジェクトのアプリケーションの man ページを熱心に読んで、そしてまた私と同 じように、どこから始めてよいのやら、証明書がどのように安全に働いている のか、さっぱり分からなかった、そんなあなた。この文章があなたの質問のほ とんどに対する回答です。 この HOWTO 文書では linux 用でないアプリケーションも扱います。と言うの も、それらが使えないなら、発行したところで証明書を使えないからです。全 てのアプリケーションをリストアップしませんが、追加の章や訂正箇所があれ ば私に報せてください。私には以下のアドレスで連絡がつきます： franck@sopac.org . この HOWTO 文書は The Linux Documentation Project において公開されたものです。ここで、この文書の最新版が得られます。（ 訳者注：翻訳版は JF Project で公開されてい ます） ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.1.1. 免責事項とライセンス この文書は役に立つだろうとの期待から配布されていますが、「何の保証もあ りません」、つまり、そこから派生する「市場性」や「特定目的適合性」につ いての保証もありません。 簡単に言うと、ここで書かれているアドバイスによってあなたの e-コマース・ アプリケーションの安全性が破られたとしても、お気の毒さま、我々のせいで はありません。ごめんなさい。 GFDL (the GNU Free Documentation License) の下で のコピーライト (c) 2001 （Franck Martin と openssl-users メイリングリス トの他の参加者による）. この文書は自由にコピーし、任意のフォーマットで配布（売るなり、捨てるな り）することができます。訂正やコメントはこの文書の責任者に報せてくださ い。この文書から派生した仕事を配布することも、以下の条件の下で許可され ます： 1. これから派生したその仕事を（sgml のような最も適切なフォーマットで） LDP (Linux Documentation Project) か、またはそのようなインターネッ ト上の公開の場所に送ること。もしそれが LDP でないときは、LDP にその 場所を報せること。 2. これと同じライセンスで、その派生した仕事をライセンスすること、また は GPL を用いること。コピーライトの告示と、少なくとも用いられたライ センスへのリンクを含めること。 3. 前の著者と主な貢献者への正当なクレジットを含めること。もし、翻訳以 外の派生物を作成しようと考えているならば、その計画をこの文書の現在 の責任者に相談すること。 もしあなたがこの HOWTO をハードコピーして出版するときには、著者に「レビ ュー用」に何部か送ってください ;-) 私がヌードルを料理するのに何かを送っ てくれるのもいいですね ;-) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.1.2. 予備知識 イントロダクションで述べたように、この文書は手にとって使う HOWTO で、 Open SSL のソフトウェアの man ページを別途、調べてもらう必要があります 。また、セキュリティ関係の本を読んで、どのようにセキュリティが危険にさ らされるのかを学ぶべきでもあります。証明書は通信の安全性を増加させるこ とを目的としていますが、あなたが行うこととの係わり合いの全てのセキュリ ティの問題を理解し、セキュリティについて Open SSL にできることと、でき ないことを理解することは、大変に重要です。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.2. SSL とは何か、証明書とは何か？ Secure Socket Layer プロトコルは Netscape 社によって web サーバとブラウ ザの間の安全な通信を保証するために作り出されました。このプロトコルは通 信の一方の端、または両端の身元を保証するために、認証局 (Certificate Authority, CA) と呼ばれる第三者を用います。以下が簡単なその仕組みです。 1. ブラウザがセキュアなページ（通常 https:// ）を要求する。 2. その web サーバが、その証明書と一緒にその公開鍵を送る。 3. ブラウザはその証明書が信用が与えられた機関（通常は信用が与えられた ルート認証局(root CA)）によって発行されたものであること、その証明書 がまだ有効であって、そして、その証明書が接続しようとしているそのサ イトと関係づけられていることをチェックする。 4. そして、ブラウザはその公開鍵を用いてランダムに選んだ対称鍵を暗号化 し、その鍵と要求された URL を暗号化したものを、他の暗号化した http データとともに送る。 5. web サーバは自分の秘密鍵を用いて、送られてきた対称鍵を復号し、その 対称鍵を用いて URL と http データを復号する。 6. web サーバは要求された html ドキュメントと http データを対称鍵で暗 号化して送り返す。 7. ブラウザはその http データと html ドキュメントを対称鍵を用いて復号 し、その情報を表示する。 以上で理解しなくてはならない概念がいくつか出てきました。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.2.1. 秘密鍵と公開鍵： 秘密鍵/公開鍵の鍵ペアを用いる暗号化は、データが一方の鍵で暗号化されると 、その対である他方の鍵でしか復号できない、ということを保証します。理解 するのが難しいですが、私を信じてうまく行くことにしてください。その鍵は 自然にあるものと似ていますが、違う使い方ができます。つまり、一方の鍵が 暗号化すると、その対の鍵で復号化できるのです。この鍵対は素数の性質に基 づいていて、それらのビット長が対の鍵なしにメッセージを復号する困難さを 保証します。鍵ペアを使う根本のアイデアは、片方の鍵を秘密にしておき（秘 密鍵）、そしてその対の他方の鍵をみんなに公開してしまう（公開鍵）ことで す。だれでもあなたに暗号化したメッセージを送ることが出来て、あなただけ がそれを復号化することが出来るのです。あなたは対になっている他方の鍵を 持っているただ一人の人なのですから。でしょう？この逆に、あるメッセージ が確かにあなたから来たものだと保証することもできます。なぜなら、あなた が自分の秘密鍵で暗号化したものは、それと対になっている公開鍵だけが正し く復号できるからです。この場合には、メッセージは安全ではなく、単にあな たが署名しただけだということに注意してください。みんながその公開鍵を持 っているのだということを忘れずに！ 残された問題の一つは通信相手の公開鍵を知ることです。通常は、証明書と同 じく公開鍵も含まれた、秘密でない署名入りメッセージを送ってもらうよう相 手に要求します。 Message-->[Public Key]-->Encrypted Message-->[Private Key]-->Message ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.2.2. 証明書： 自分が正しい人物、またはこの場合の方が多いでしょうが、正しい web サイト とやりとりをしているのだと、どうすれば知ることが出来るのでしょう。ええ 、web サイトの所有者は彼らが主張している人物たちだと保証するために、大 変な手間をかけています（もし彼らがセキュリティについて真剣ならばですが ）。この人たちと、その通信相手であるあなたは、暗黙のうちに、彼、または 彼女の証明書（ルート証明書）を自分のブラウザに読み込んでいること、を仮 定しなければなりません。証明書にはその証明書の所有者の情報、例えば e-mail アドレスや、名前や、証明書の使用目的、有効期間、情報の場所、また は通常名(Common Name, CN)を含む識別名(Distinguish Name, DN) （web サイ トのアドレスや e-mail アドレスは用法に依存します）、そしてこの情報に保 証を与えた（つまり署名した）人物の証明書 ID が含まれています。さらに、 証明書はその公開鍵を含み、最後に、その証明書全体が改竄されていないこと を保証するためのハッシュ値を含んでいます。この証明書に署名した人を信用 するという選択をした以上、それゆえにこの証明書の内容も信じることになり ます。これは証明書の信用ツリーまたは認証径路と呼ばれるものです。通常は 、あなたのブラウザやアプリケーションは既に、よく知られている認証機関 (Certificate Authorities, CA) のルート証明書か、ルート認証局証明書(root CA Certificates)を組み込み済みです。 CA（認証局）は全ての署名入り証明書 のリストと、同じように無効になった証明書のリストを維持しています。署名 された証明書だけが改竄不可能なのですから、証明書はそれが署名されるまで は安全ではありません。自分自身で自分の証明書に署名することもでき、これ は自己署名証明書と呼ばれています。全ての root CA（ルート認証局）の証明 書は自己署名しています。 Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: md5WithRSAEncryption Issuer: C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, CN=SOPAC Root CA/Email=administrator@sopac.org Validity Not Before: Nov 20 05:47:44 2001 GMT Not After : Nov 20 05:47:44 2002 GMT Subject: C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, CN=www.sopac.org/Email=administrator@sopac.org Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:ba:54:2c:ab:88:74:aa:6b:35:a5:a9:c1:d0:5a: 9b:fb:6b:b5:71:bc:ef:d3:ab:15:cc:5b:75:73:36: b8:01:d1:59:3f:c1:88:c0:33:91:04:f1:bf:1a:b4: 7a:c8:39:c2:89:1f:87:0f:91:19:81:09:46:0c:86: 08:d8:75:c4:6f:5a:98:4a:f9:f8:f7:38:24:fc:bd: 94:24:37:ab:f1:1c:d8:91:ee:fb:1b:9f:88:ba:25: da:f6:21:7f:04:32:35:17:3d:36:1c:fb:b7:32:9e: 42:af:77:b6:25:1c:59:69:af:be:00:a1:f8:b0:1a: 6c:14:e2:ae:62:e7:6b:30:e9 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: FE:04:46:ED:A0:15:BE:C1:4B:59:03:F8:2D:0D:ED:2A:E0:ED:F9:2F X509v3 Authority Key Identifier: keyid:E6:12:7C:3D:A1:02:E5:BA:1F:DA:9E:37:BE:E3:45:3E:9B:AE:E5:A6 DirName:/C=FJ/ST=Fiji/L=Suva/O=SOPAC/OU=ICT/CN=SOPAC Root CA/Email=administrator@sopac.org serial:00 Signature Algorithm: md5WithRSAEncryption 34:8d:fb:65:0b:85:5b:e2:44:09:f0:55:31:3b:29:2b:f4:fd: aa:5f:db:b8:11:1a:c6:ab:33:67:59:c1:04:de:34:df:08:57: 2e:c6:60:dc:f7:d4:e2:f1:73:97:57:23:50:02:63:fc:78:96: 34:b3:ca:c4:1b:c5:4c:c8:16:69:bb:9c:4a:7e:00:19:48:62: e2:51:ab:3a:fa:fd:88:cd:e0:9d:ef:67:50:da:fe:4b:13:c5: 0c:8c:fc:ad:6e:b5:ee:40:e3:fd:34:10:9f:ad:34:bd:db:06: ed:09:3d:f2:a6:81:22:63:16:dc:ae:33:0c:70:fd:0a:6c:af: bc:5a -----BEGIN CERTIFICATE----- MIIDoTCCAwqgAwIBAgIBATANBgkqhkiG9w0BAQQFADCBiTELMAkGA1UEBhMCRkox DTALBgNVBAgTBEZpamkxDTALBgNVBAcTBFN1dmExDjAMBgNVBAoTBVNPUEFDMQww CgYDVQQLEwNJQ1QxFjAUBgNVBAMTDVNPUEFDIFJvb3QgQ0ExJjAkBgkqhkiG9w0B CQEWF2FkbWluaXN0cmF0b3JAc29wYWMub3JnMB4XDTAxMTEyMDA1NDc0NFoXDTAy MTEyMDA1NDc0NFowgYkxCzAJBgNVBAYTAkZKMQ0wCwYDVQQIEwRGaWppMQ0wCwYD VQQHEwRTdXZhMQ4wDAYDVQQKEwVTT1BBQzEMMAoGA1UECxMDSUNUMRYwFAYDVQQD Ew13d3cuc29wYWMub3JnMSYwJAYJKoZIhvcNAQkBFhdhZG1pbmlzdHJhdG9yQHNv cGFjLm9yZzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAulQsq4h0qms1panB 0Fqb+2u1cbzv06sVzFt1cza4AdFZP8GIwDORBPG/GrR6yDnCiR+HD5EZgQlGDIYI 2HXEb1qYSvn49zgk/L2UJDer8RzYke77G5+IuiXa9iF/BDI1Fz02HPu3Mp5Cr3e2 JRxZaa++AKH4sBpsFOKuYudrMOkCAwEAAaOCARUwggERMAkGA1UdEwQCMAAwLAYJ YIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1Ud DgQWBBT+BEbtoBW+wUtZA/gtDe0q4O35LzCBtgYDVR0jBIGuMIGrgBTmEnw9oQLl uh/anje+40U+m67lpqGBj6SBjDCBiTELMAkGA1UEBhMCRkoxDTALBgNVBAgTBEZp amkxDTALBgNVBAcTBFN1dmExDjAMBgNVBAoTBVNPUEFDMQwwCgYDVQQLEwNJQ1Qx FjAUBgNVBAMTDVNPUEFDIFJvb3QgQ0ExJjAkBgkqhkiG9w0BCQEWF2FkbWluaXN0 cmF0b3JAc29wYWMub3JnggEAMA0GCSqGSIb3DQEBBAUAA4GBADSN+2ULhVviRAnw VTE7KSv0/apf27gRGsarM2dZwQTeNN8IVy7GYNz31OLxc5dXI1ACY/x4ljSzysQb xUzIFmm7nEp+ABlIYuJRqzr6/YjN4J3vZ1Da/ksTxQyM/K1ute5A4/00EJ+tNL3b Bu0JPfKmgSJjFtyuMwxw/Qpsr7xa -----END CERTIFICATE----- もうお気づきになっているように、証明書はその発行者への参照を含んでいて 、証明書の所有者の公開鍵、証明書の有効期間とこの証明書が改竄されていな いことを保証するための証明書の署名が含まれています。証明書は秘密鍵を含 みません。秘密鍵はどんな形式であろうが決して誰かに渡すべきでないからで す。この証明書は所有者に暗号化メッセージを送り、そしてメッセージがこの 証明書の所有者によって署名されていることを保証するための、全ての情報を 含んでいます。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.2.3. 対称鍵： ええ、秘密鍵/公開鍵暗号アルゴリズムは偉大です。しかし、これは通常使うも のとしては現実的でありません。復号化するためには別の鍵が必要ですから、 これは非対称的です。暗号化と復号化に同じ鍵を使うことはできません。復号 化と暗号化に同じ鍵を用いるアルゴリズムは対称鍵を持つと呼ばれます。対称 なアルゴリズムは非対称なアルゴリズムよりずっと速く仕事をこなします。し かし、対称鍵は潜在的に非常に危険です。もし敵がその鍵を手に入れたら、あ なたはもはや秘密の情報はなくなります。ですから、敵の手に渡すことなくそ の鍵を相手に送らなければなりません。ご存知のように、インターネット上に は安全なものは何一つありません。この解決策はその対称鍵を非対称アルゴリ ズムで暗号化したメッセージのカプセルの中に入れることです。秘密鍵は決し て誰にも渡しませんから、公開鍵で暗号化されたメッセージは安全です（正確 に言えば、比較的安全です。死と税金以外に確かなものは何もないのですから ）。対称鍵はランダムに選ばれますから、もし対称鍵が発見されても、次の通 信では全く異なることになります。 Symetric Key-->[Public Key]-->Encrypted Symetric Key-->[Private Key]-->Symetric Key ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.2.4. 暗号化アルゴリズム： 可能な暗号化アルゴリズムには、色々な鍵の長さの、対称的なもの、非対称的 なもの、と様々あります。通常は、アルゴリズムで特許をとることはできませ ん。もし、ポアンカレが自分のアルゴリズムの特許をとっていたら、アインシ ュタインを訴えることができたでしょう…そういうわけでアルゴリズムでは特 許をとることはできません、ただしアメリカ合衆国が主な例外です。 OpenSSL は、アルゴリズムで特許がとることができない、そして暗号化技術が軍や情報 機関のような国家機関だけに制限されてはいない国で開発されています。ブラ ウザと web サーバのネゴシエーション（プロトコルのやりとり）の間に、その 双方のアプリケーションは望ましい順番に並べた可能なアルゴリズムのリスト を見せあいます。そして共通の望ましいアルゴリズムが選ばれます。 OpenSSL は、特定のアルゴリズムを含めたり、除いたりした形でコンパイル可能ですか ら、制限が適用されている多くの国でも使えるのです。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.2.5. ハッシュ ハッシュ（ハッシュ値）とはハッシュ関数によってメッセージから作られたあ る数字のことです。これは一方通行関数で、つまり、そのハッシュから元のメ ッセージを得ることが不可能であることを意味しています。しかし、ハッシュ は元のメッセージがほんの少し変更されても劇的に変化します。よって、その ハッシュを変えないままメッセージを変形することは非常に困難です。ハッシ ュはメッセージ要約 (message digest) とも呼ばれます。ハッシュ関数はパス ワード方式の仕組みや、アプリケーションがオリジナルであることを保証する ためや（MD5 チェックサム）、一般にはメッセージが改竄されていないことを 確証するために使われます。 IETF (Internet Engineering Task Force) はい くつかの技術的な理由から MD5 より SHA1 の方が望ましいハッシュ関数である と考えているようです（RFC2459 7.1.2. と 7.1.3. を参照のこと）。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.2.6. 署名： メッセージに署名することは、そのメッセージの真正性をあなた自身が保証し た、ということを意味します（ほとんどの場合はあなたが著者でしょうが、必 ずしもそうでなくても構いません）。そのメッセージは普通のテキストであっ たり、誰かの証明書であるという場合もあるでしょう。あなたがメッセージに 署名するためには、まずメッセージのハッシュを作成し、あなたの秘密鍵によ ってそのハッシュを暗号化して、その暗号化されたハッシュと署名された証明 書をメッセージに添付します。これを受け取った方は、メッセージのハッシュ を独立に再び作成し、あなたの署名入りの証明書から取り出したあなたの公開 鍵で復号化して元のハッシュを得て、この二つのハッシュが等しいかどうかを チェックし、最後に証明書をチェックします。 メッセージに署名する他の利点は、全ての受け取り手に対して自動的に公開鍵 と証明書を送ることになることです。 通常、署名には二通りの方法があります。署名の中にテキストメッセージを（ 区切り指定文字を入れて）カプセル化する形式と、メッセージを署名と一緒に コード化してしまう方法です。後の形式は非常に単純な暗号化で、埋め込まれ た公開鍵を読めればどんなソフトウェアでも復号できます。最初の形式の利点 は、メッセージが人間に読むことができて、それを読むユーザへとメッセージ を渡すクライアントに何の問題も生じない一方、二番目の形式ではメッセージ が改竄されていると、メッセージの一部を読むことさえできないことです。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.2.7. パスフレーズ： “パスフレーズはパスワードより長いという以外にはパスワードと同じような ものです”。初期には Unix システムでのパスワードは８文字までに限られて いたので、より長いパスワードをパスフレーズと言うのです。パスワードが長 ければ長いほど、推測するのが難しくなります。現在の Unix システムでは MD5 を使うことで、パスワードの長さの制限はなくなっています。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.2.8. 公開鍵基盤 (PKI, Public Key Infrastracture) 公開鍵基盤(PKI, Public Key Infrastructure)とは、証明書に署名し、無効に なった証明書のリストを維持し、公開鍵を配布するといったことを可能にする ためのソフトウェアとデータベースのシステムのことです。通常は、web サイ トか ldap サーバ、またはその両方を通じてこれにアクセスします。そこでは 誰かが、あなたが本当にあなたであることをチェックしていることになるでし ょう。個々のアプリケーションの安全性を高めるには、良く知られた商用の PKI を用いることができます。これは、おそらくその root CA の証明書が、ブ ラウザやアプリケーションに既に組み込まれているからです。問題点は、安全 に e-mail を使いたい場合で、あなたは e-mail の一般的なタイプの証明書を 手に入れるか、または証明書/e-mail ごとに一年あたり約 100 USドルを払わな くてはなりません。もし、以前に（公開鍵を含んだ）証明書つきの e-mail を 一度も受け取っていないと、誰かの公開鍵を見つける方法もありません。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.3. S/MIME その他のプロトコルってどんなもの？ SSL は web サーバのために開発されたので、任意のプロトコルを暗号化するた めに用いることが可能です。どんなプロトコルでも SSL の中にカプセル化でき ます。この方法は IMAPS, POPS, SMTPS, ... などで用いられています。これら の安全性を高めたプロトコルは、その安全でないバージョンとは異なるポート 番号を使っています。また、SSL はどんな通信を暗号化するのにも使えます。 通信相手と直接の（即時の）接続をする必要はありません。 S/Mime はそんな プロトコルで、通常の e-mail の内側に、暗号化したメッセージをカプセル化 するのです。メッセージは受け取る相手の公開鍵で暗号化されます。あなたは web サイトか、レポジトリから公開鍵を手に入れるか、または公開鍵と証明書 を e-mail で送ってもらうように相手に要求します（証明書は本当に正しい相 手に話しかけているか保証するためです）。 逆の順序で、ブラウザは自分自身の署名された証明書を、身元確認用としてweb サーバに送ることができます。しかし、ブラウザの証明書は誰でも CA web サ イトで手に入れることができます。そうです、しかし送られてきた証明書は秘 密鍵で暗号化されていて、その公開鍵でしか復号できません。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Chapter 2. 証明書の運用 2.1. インストール 今では、OpenSSL のインストールについて、そんなに心配する必要はありませ ん。と言うのも、ほとんどのディストリビューションではパッケージ管理アプ リケーションを用いているからです。各ディストリビューションのドキュメン トを参照するか、 OpenSSl tarball に含まれている README と INSTALL ファ イルを読んでください。この HOWTO を証明書を扱う HOWTO よりも、インスト ール HOWTO にしてしまうことは避けたいと思います。 ここでは、後の例を理解するために知る必要のある標準的なインストールオプ ションをいくつか紹介しておきます。場合によっては変更が必要かもしれませ ん。 全ての OpenSSL 証明書のためのディレクトリは /var/ssl/ です。この文書の 中の全てのコマンドとパスはこのディレクトリから始まっています。これは必 須ではありませんが、以下の例を理解する役に立つでしょう。 デフォルトの OpenSSL は /usr/lib/ssl/openssl.cnf で設定ファイルを探しま す。ですから例えば、openssl ca や openssl req のコマンドに常に -config /etc/openssl.cnf を加えてください。私は /etc/openssl.cnf を用いることに しますので、私の全ての設定ファイルは /etc 以下にあることになります。 ユーティリティと他のライブラリは /usr/lib/ssl 以下におかれています。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.1.1. CA.pl ユーティリティ ユーティリティ CA.pl が /usr/sbin のようなアクセス可能なディレクトリに あることを確認してください。 CA.pl は /usr/lib/ssl ディレクトリの中で見 つけられます。 CA.pl は openssl コマンドの複雑さを覆い隠すユーティリテ ィです。以下の全ての例で、私が CA.pl を使うときは、その openssl での等 価コマンドを括弧の中に書くことにします。 <-- /usr/sbin/CA.pl needs to be modified to include -config /etc/ openssl.cnf in ca and req calls. --> /usr/sbin/CA.pl は ca と req コー ルでは -config /etc/openssl.cnf をつけて変形する必要があります。 #$SSLEAY_CONFIG=$ENV{"SSLEAY_CONFIG"}; $SSLEAY_CONFIG="-config /etc/openssl.cnf"; #$CATOP="./demoCA"; $CATOP="/var/ssl"; ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.1.2. openssl.cnf ファイル /etc/openssl.cnf は input エントリーを最小限にするように適切に設定しな ければいけません。 #---Begin--- # # OpenSSL example configuration file. # OpenSSL 設定ファイル例 # This is mostly being used for generation of certificate requests. # これは主に証明書要求の生成のために使われるもの。 # RANDFILE = $ENV::HOME/.rnd oid_file = $ENV::HOME/.oid oid_section = new_oids # To use this configuration file with the "-extfile" option of the # "openssl x509" utility, name here the section containing the # X.509v3 extensions to use: # この設定ファイルを "openssl x509" ユーティリティの "-extfile" # オプションとともに使うためには、用いる X509v3 拡張を # 含むセクションにここで名前をつける： # extensions = # (Alternatively, use a configuration file that has only # X.509v3 extensions in its main [= default] section.) # （または、メインの[=default]セクションで X.509v3 拡張 # だけを持つ設定ファイルを使う） [ new_oids ] # We can add new OIDs in here for use by 'ca' and 'req'. # Add a simple OID like this: # ここで 'ca' と 'req' によって用いるための新たな OID らを追加。 # 一つの OID をこのように追加する： # testoid1=1.2.3.4 # Or use config file substitution like this: # または以下のように設定ファイルの挿入を使う： # testoid2=${testoid1}.5.6 #################################################################### [ ca ] default_ca = CA_default # The default ca section　デフォルト CA セクション #################################################################### [ CA_default ] dir = /var/ssl # Where everything is kept 全てが保存されている場所 certs = $dir/certs # Where the issued certs are kept 発行された証明書が保存されている場所 crl_dir = $dir/crl # Where the issued crl are kept 発行された crl が保存されている場所 database = $dir/index.txt # database index file. データベースインデックスファイル new_certs_dir = $dir/newcerts # default place for new certs.新しい証明書をおくデフォルトの場所 certificate = $dir/cacert.pem # The CA certificate （CA 証明書） serial = $dir/serial # The current serial number 現在のシリアル番号 crl = $dir/crl.pem # The current CRL 現在の CRL private_key = $dir/private/cakey.pem # The private key 秘密鍵 RANDFILE = $dir/private/.rand # private random number file 秘密の乱数ファイル x509_extensions = usr_cert # The extentions to add to the cert 証明書に追加する拡張 # Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs # so this is commented out by default to leave a V1 CRL. # CRL に追加する拡張。注意：Netscape communicator は V2 CRL は受け入れない # よって、これは V1 CRL を残すためデフォルトでコメントアウト。 # crl_extensions = crl_ext default_days = 365 # how long to certify for 有効期間 default_crl_days= 7 # how long before next CRL 次の CRL までの期間 default_md = sha1 # which md to use. 用いる md の種類 preserve = no # keep passed DN ordering パスした DN 順序を保存 # A few difference way of specifying how similar the request should look # For type CA, the listed attributes must be the same, and the optional # and supplied fields are just that :-) # 要求の類似性を特定する二、三の違った方法 # タイプ CA については、リストされた属性は同じでなくてならず、 # 追加されたフィールドと供給されたフィールドはまさにそれで :-) policy = policy_match # For the CA policy （CA のポリシー） [ policy_match ] countryName = match stateOrProvinceName = optional localityName = match organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional # For the 'anything' policy # At this point in time, you must list all acceptable 'object' # types. # 「なんでも」ポリシー # この時点で、全ての受け入れ可能な 'object'タイプをリスト [ policy_anything ] countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional #################################################################### [ req ] default_bits = 1024 default_keyfile = privkey.pem distinguished_name = req_distinguished_name attributes = req_attributes default_md = sha1 x509_extensions = v3_ca # The extentions to add to the self signed cert # 自己署名証明書へ追加される拡張項目 # Passwords for private keys if not present they will be prompted for # 秘密鍵用のパスワード、存在しないとき入力を促される # input_password = secret # output_password = secret # This sets a mask for permitted string types. There are several options. # 許可される文字列型のためのマスクを設定。以下のような色々なオプションがある。 # default: PrintableString, T61String, BMPString. # pkix : PrintableString, BMPString. # utf8only: only UTF8Strings. # nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings). # MASK:XXXX a literal mask value. # WARNING: current versions of Netscape crash on BMPStrings or UTF8Strings # so use this option with caution! # 警告：Netscape の現在のヴァージョンは BMPStrings か UTF8Strings では # クラッシュするので、このオプションは注意して！ string_mask = nombstr # req_extensions = v3_req # The extensions to add to a certificate request # 証明書要求に追加する拡張項目 [ req_distinguished_name ] countryName = Country Name (2 letter code) countryName_default = FJ countryName_min = 2 countryName_max = 2 stateOrProvinceName = State or Province Name (full name) #国名・州名（フルネームで） stateOrProvinceName_default = Fiji localityName = Locality Name (eg, city) # 地方名（市など） localityName_default = Suva 0.organizationName = Organization Name (eg, company) #組織名（会社など） 0.organizationName_default = SOPAC # we can do this but it is not needed normally :-) # 可能だが、普通は必要ない :-) #1.organizationName = Second Organization Name (eg, company) #第二組織名 #1.organizationName_default = World Wide Web Pty Ltd organizationalUnitName = Organizational Unit Name (eg, section) #組織単位名 organizationalUnitName_default = ITU commonName = Common Name (eg, YOUR name) #通常の名前（あなたの名前など） commonName_max = 64 emailAddress = Email Address #メイルアドレス emailAddress_max = 40 # SET-ex3 = SET extension number 3 [ req_attributes ] challengePassword = A challenge password #チャレンジパスワード challengePassword_min = 4 challengePassword_max = 20 unstructuredName = An optional company name #オプションの会社名 [ usr_cert ] # These extensions are added when 'ca' signs a request. # This goes against PKIX guidelines but some CAs do it and some software # requires this to avoid interpreting an end user certificate as a CA. # これらの拡張項目は 'ca' が要求に署名するとき追加される。 # これは PKIX 勧告に反するが、CA にはそうするものもあり、 # ソフトウェアによってはエンドユーザ証明書を CA と解釈するのを避けるため # 要求するものもある。 basicConstraints=CA:FALSE # Here are some examples of the usage of nsCertType. If it is omitted # the certificate can be used for anything *except* object signing. # ここは nsCertType の使い方の例。もし省略されれば、 # その証明書はオブジェクト署名を *除いて* 何にでも用いることができる。 # This is OK for an SSL server. # SSL サーバのため、これは OK. # nsCertType = server # For an object signing certificate this would be used. # オブジェクト署名証明書のために用いられることも。 # nsCertType = objsign # For normal client use this is typical # 普通のクライアントの使用では、これは典型的。 # nsCertType = client, email # and for everything including object signing: # そして、オブジェクト署名を含む全てについて： # nsCertType = client, email, objsign # This is typical in keyUsage for a client certificate. # これはクライアントの証明書についての keyUsage では典型的 # keyUsage = nonRepudiation, digitalSignature, keyEncipherment # This will be displayed in Netscape's comment listbox. # これは Netscape のコメントリストボックスに表示される。 nsComment = "Certificate issued by https://www.sopac.org/ssl/" # PKIX recommendations harmless if included in all certificates. # すべての証明書に含まれていれば PKIX 勧告は問題なし。 subjectKeyIdentifier=hash authorityKeyIdentifier=keyid,issuer:always # This stuff is for subjectAltName and issuerAltname. # Import the email address. # この内容は subjectAltName と issuerAltname のため。 # email アドレスをインポート。 # subjectAltName=email:copy # Copy subject details # 項目の詳細をコピー # issuerAltName=issuer:copy # This is the base URL for all others URL addresses # if not supplied # これは、指定されないときの、全てのほかの URL アドレスの # ためのベース URL として使われる。 nsBaseUrl = https://www.sopac.org/ssl/ # This is the link where to download the latest Certificate # Revocation List (CRL) # これは最新の失効証明書リスト(CRL)をダウンロードする # 場所のリンク nsCaRevocationUrl = https://www.sopac.org/ssl/sopac-ca.crl # This is the link where to revoke the certificate # これは証明書を破棄（無効化）するための場所のリンク nsRevocationUrl = https://www.sopac.org/ssl/revocation.html? # This is the location where the certificate can be renewed # 証明書を更新するための場所のリンク nsRenewalUrl = https://www.sopac.org/ssl/renewal.html? # This is the link where the CA policy can be found # CA ポリシーがある場所のリンク nsCaPolicyUrl = https://www.sopac.org/ssl/policy.html # This is the link where we can get the issuer certificate # 発行者の証明書がある場所のリンク issuerAltName = URI:https://www.sopac.org/ssl/sopac.crt # This is the link where to get the latest CRL # 最新の CRL がある場所のリンク crlDistributionPoints = URI:https://www.sopac.org/ssl/sopac-ca.crl [ v3_ca ] # Extensions for a typical CA # 典型的な CA のための拡張項目 # PKIX recommendation. # PKIX 勧告の推奨 subjectKeyIdentifier=hash authorityKeyIdentifier=keyid:always,issuer:always # This is what PKIX recommends but some broken software chokes on critical # extensions. # PKIX はそう勧めているが、いいかげんなソフトウェアには # critical 拡張を受け入れないものもある。 # basicConstraints = critical,CA:true # So we do this instead. # だから代わりにこうする。 basicConstraints = CA:true # Key usage: this is typical for a CA certificate. However since it will # prevent it being used as an test self-signed certificate it is best # left out by default. # 鍵の使い方： CA 証明書の場合に典型的。しかしながら、 # テスト用自己署名証明書として用いられるのを妨げるだろうから、 # デフォルトで省いておくのがベスト。 # keyUsage = cRLSign, keyCertSign # Some might want this also # これも必要な場合もある # nsCertType = sslCA, emailCA # Include email address in subject alt name: another PKIX recommendation # 本人の別名に email アドレスを含める： PKIX のまた別の推奨 # subjectAltName=email:copy # Copy issuer details # 発行者の詳細をコピー # issuerAltName=issuer:copy # RAW DER hex encoding of an extension: beware experts only! # 拡張の RAW DER 16進エンコーディング：ご用心、エキスパートのみ！ # 1.2.3.5=RAW:02:03 # You can even override a supported extension: # サポートされた拡張に優先させることも可能 # basicConstraints= critical, RAW:30:03:01:01:FF # This will be displayed in Netscape's comment listbox. # これが Netscape のコメントリストボックスに表示される。 nsComment = "Certificate issued by https://www.sopac.org/ssl/" # This is the base URL for all others URL addresses # if not supplied # 与えられていないなら # 他の全ての URL アドレスのための使うベース URL. nsBaseUrl = https://www.sopac.org/ssl/ # This is the link where to download the latest Certificate # Revocation List (CRL) # 最新の失効証明書リスト（CRL)をダウンロードするための # 場所のリンク nsCaRevocationUrl = https://www.sopac.org/ssl/sopac-ca.crl # This is the link where to revoke the certificate # 証明書を破棄（無効化）するための場所のリンク nsRevocationUrl = https://www.sopac.org/ssl/revocation.html? # This is the location where the certificate can be renewed # 証明書を更新するための更新のリンク nsRenewalUrl = https://www.sopac.org/ssl/renewal.html? # This is the link where the CA policy can be found # CA ポリシーがある場所のリンク nsCaPolicyUrl = https://www.sopac.org/ssl/policy.html # This is the link where we can get the issuer certificate # 発行者の証明書がある場所のリンク issuerAltName = URI:https://www.sopac.org/ssl/sopac.crt # This is the link where to get the latest CRL # 最新の CRL がある場所のリンク crlDistributionPoints = URI:https://www.sopac.org/ssl/sopac-ca.crl [ crl_ext ] # CRL extensions. # Only issuerAltName and authorityKeyIdentifier make any sense in a CRL. # CRL 拡張項目。 # issuerAltName と authorityKeyIdentifier 項目だけが CRL の中で意味を持つ # issuerAltName=issuer:copy authorityKeyIdentifier=keyid:always,issuer:always #----End---- openssl.cnf について二、三のコメント。 ・ 変数名はデフォルトの値には接尾辞として _default を使え、要求される 文字数の最小値には _min が、最大値には _max が使える。 ・ このファイルは変数の [セクション] で構成されている。 dir: ベースになるディレクトリを特定する。 default_ca: どのセクションがデフォルトの証明書についての変数を含むか特定する。 basicConstraints: 証明書の使い方を定義する。例えば、CA:TRUE は、その証明書が root CA 証明書であること。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.1.3. 認証局を作る 認証局を作るには、正確に openssl.cnf を編集したのち、以下のコマンドを使 います： CA.pl -newca このユーティリティはあなたの CA 証明書として発効させる証明書ファイルを 選ぶか、または新たに作るように尋ねてきます。練習のために以下の手順に従 って一つ作ってみましょう。次の章では、このデフォルトで作成された CA を 上書きして、もっと長く使える新しいものを作成します。 CA.pl は 365 日間 の証明書だけしか作ってくれません。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.2. ルート認証局証明書を作る CA.pl -newcert (openssl req -config /etc/openssl.cnf -new -x509 -keyout newreq.pem \ -out newreq.pem -days 365) 自己署名証明書を作りましょう（認証局のためです）。結果のファイルは newreq.pem です。 Common Name (CN) には “ACME root Certificate” のよ うなものを用います。このファイルは cacert.pem と private/cakey.pem の二 つのファイルに分割する必要があります。 -RSA PRIVATE KEY- の部分は pribate/cakey.pem の方に入り、 -CERTIFICATE- の部分は cacert.pem の中に 入ります。作業が終わったら、newreq.pem を削除しましょう。 さて、index.txt ファイルが空であること、そのファイルシリアルが 01 を含 むことを確認しましょう。 ルート証明書とこのルートによって署名された全ての証明書はルート証明書が 失効した時に変更しなければなりませんから、有効期間を延ばしたいと思うか も知れません。認証を専門にする会社のルート証明書の標準的な有効期間は、 5 年から 10 年くらいだと思います。 openssl req -config /etc/openssl.cnf -new -x509 -keyout private/cakey.pem \ -out cacert.pem -days 3650 この最後のコマンドはファイルを要求された場所におき、 10 年間有効なルー ト CA を作成しますから、 “CA.pl -newcert” より良いでしょう。 この自己署名ルート証明書は、他の証明書を署名するためだけに用いられるこ とを肝に銘じて下さい。秘密鍵は極めて注意深く扱わねばなりません。それを 守っているパスフレーズを削除して、けっしてこれを漏らしてはいけません。 秘密鍵をフロッピーディスクにおいて、他の証明書に署名するときにのみ、ロ ードする人もいるでしょう。このようにフロッピーに保存しておけば、もしコ ンピュータがハックされたときにも、ハッカーが秘密鍵を手に入れることは物 理的に不可能になります。 これで、ルート認証局を持つことができました。他の人々にはこの自己署名ル ート CA 証明書を信用してもらって、これをダウンロードし、ブラウザに登録 してもらう必要があります。 この証明書で他の証明書に署名したいときにはその都度、パスフレーズをタイ プしなければなりません。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.3. 非ルート認証局証明書を作る この手続きについてはまだ確信がないので、間違いがあったら訂正してくださ い。 それが有効で、署名能力を与えられて発行されている限り、勝手な署名入り証 明書を使って、他の証明書に署名することは可能です。ですから、証明書要求 と秘密鍵を作り、第三者によって証明書に署名してもらい、署名入り証明書と 秘密鍵をインストールすることができます。 -PRIVATE KEY- の部分は private /cakey.pem ファイルに入り、 -CERTIFICATE- の部分は cacert.pem に入りま す。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.4. 信用が与えられたルート証明書として CA ルート証明書をインストールす る まず、-CERTIFICATE- セクションだけを保存するためにそのテキストから証明 書を分離します。 openssl x509 -in cacert.pem -out cacert.crt このファイルを http://mysite.com/ssl/cacert.crt のようなあなたの web サ イト上においてください。その web サーバは .crt ファイルを mime 形式で受 付けるよう設定されていなければいけません。これで証明書はブラウザからダ ウンロードされ、保存されるよう準備されました。 人々が既にブラウザに証明書をダウンロードしているのはありそうにないこと ですから、 web サイト上にこのルート CA 証明書を公開することは重要です。 誰かがこの web サイトに成り代わって、このルート CA 証明書をすりかえる可 能性があることに注意してください。証明書を手に入れるための方法をユーザ のために複数用意しておけば、ハッカーが全てを駄目にしてしまうことはまず ないでしょう。 Microsoft は証明されたルート証明書をユーザの internet explorer に送り出 す windows アップデート機能を提唱しています。 Microsoft に自分のルート 証明書を彼らのデータベースに付け加えてくれるようにコンタクトを取ること ができます。そして、Microsoft の将来のリリースに入れてくれるかもしれま せん。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.4.1. Netscape/Mozilla では Netscape を用いて、web サーバかファイルシステムから証明書をダウンロード してください。 Netscape は、それがルート証明書であることを自動的に認識 し、それを保存するように促すでしょう。ウィザードに従って証明書をインス トールしてください。ウィザードの最後に、この証明書を信用するアプリケー ションのタイプはどれか特定しなければなりません： web サイトセキュリティ 、e-mail 署名、コード署名などです。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.4.2. Galeon では Galeon は Mozilla と同じ HTML レンダリングエンジンを用いているので、 Mozilla と似た動作をします。しかし、Galeon には証明書を扱うツールは含ま れていません。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.4.3. Opera では 準備中。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.4.4. Internet Explorer では ブラウザで証明書のアドレスをクリックして、ディスクにファイルを保存して ください。ファイルをダブルクリックすると証明書インストールウィザードが 立ち上がります。この証明書は自己署名されていますから、Internet Explorer は信用されたルート認証局として自動的にインストールします。以降は、 Internet Explorer は文句を言わず、ルート CA 証明書によって署名された証 明書も同様に信用するでしょう。 Internet Explorer から証明書を表示させることもできます。インストール証 明書のボタンをクリックすると、証明書インストールウィザードが立ち上がり ます。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.5. 証明書の運用 2.5.1. 証明書要求の生成と署名 CA.pl -newreq (openssl req -config /etc/openssl.cnf -new -keyout newreq.pem -out newreq.pem \ -days 365) 新しい秘密鍵と証明書要求を生成して、newreq.pem として保存します。 Common Name (CN) に証明書の主な使用法を入力します。例えば、セキュアな web サイト www.sopac.org を持ちたい場合は、 www.sopac.org と入力、セキ ュアな e-mail として franck@sopac.org を持ちたい場合は、 franck@sopac.org などです。 CA.pl -sign (openssl ca -config /etc/openssl.cnf -policy policy_anything -out newcert.pem \ -infiles newreq.pem) この cacert.pem を用いて要求に署名をし、 newcert.pem として証明書をコミ ットすることになります。この cacert.pem （あなたの CA 証明書）のパスフ レーズを入力する必要があります。 newcerts/xx.pem ファイルが作られ、 index.txt と serial がアップデートされます。 あなたの秘密鍵は newreq.pem の中の -PRIVATE KEY- に、証明書は nercert.pem の -CERTIFICATE- に入ります。 newcert.pem のコピーが index.txt の中の適切なエントリーが作られるととも に newcerts/ 以下に置かれ、クライアントは証明書の真正性を確認するために web サーバを通じてこの情報を要求することができるようになります。 newreq.pem ファイルは証明書要求を含んでいますが、秘密鍵も含んでいますの で、取り扱いに注意してください。 -PRIVATE KEY- セクションは署名をすると きには不要です。ですから、誰か他の人にあなたの証明書要求に署名してもら うのなら、ファイルから -PRIVATE KEY- セクションを取り除いてあることを確 認してください。あなたが誰かの証明書要求に署名するときには、この人にそ の秘密鍵ではなく -CERTIFICATE REQUEST- セクションを要求してください。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.5.2. 証明書の破棄（無効化） 証明書を破棄（無効化）するには単純に以下のようなコマンドを命令します： openssl -revoke newcert.pem データベースがアップデートされ、その証明書は失効した(revoked)と印しがつ けられます。ここで、新たな失効証明書リストを生成する必要があります。 openssl ca -gencrl -config /etc/openssl.cnf -out crl/sopac-ca.crl この失効証明書リスト(Certificate Revokation List, CRL) ファイルはあなた の web サイトから取得できるようにしなければなりません。 証明書を破棄する時に、crldays, crlhours, crlexts のパラメータを付け加え る必要があるかもしれません。最初の二つのパラメータはいつ次の CRL がアッ プデートされるかを示し、最後のものは CRL v1 の代わりに CRL v2 を生成す るために、 openssl.cnf で crl_exts セクションを用いることを示しています 。 openssl ca -gencrl -config /etc/openssl.cnf -crldays 7 -crlexts crl_ext \ -out crl/sopac-ca.crl ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.5.3. 証明書の更新 ユーザはあなたにその古い証明書要求を送り、その秘密鍵に基づいて新しいも のを作成します。 まずあなたは、以前の証明書を破棄（無効化）し、再び証明書要求に署名しな ければなりません。 古い証明書を見つけるには、要求に対応したその識別名 (Distinguished Name, DN) を index.txt ファイルの中で探します。シリアル番号 を得て、破棄 手続きのための証明書として cert/.pem ファイルを用いてください。 新しい証明書の有効期間の開始日と終了日を正しく設定する必要がありますか ら、以下のように手動で証明書に署名しましょう。 openssl ca -config /etc/openssl.cnf -policy policy_anything -out newcert.pem \ -infiles newreq.pem -startdate [now] -enddate [previous enddate+365days] [now] と [previous enddate+365days] を正しい値で置き換えてください。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.5.4. 証明書の表示 コード化された形式で証明書を保存しているかも知れませんが、その場合、証 明書の詳細を実際に読むには以下のコマンドを使います： openssl x509 -in newcert.pem -noout -text ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.5.5. index.txt ファイル index.txt の中には OpenSSL によって運用される様々な証明書があります。各 エントリは破棄されたもの(Revoked)には R, 有効なもの(Valid)には V, 期限 切れのもの(expired)には E と印しがつけられています。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.5.6. web ベースの認証局を立ち上げる あなたが認証局(CA)であるためには以下のような若干の要件があります： 1. ルート CA 証明書が公開されており、アプリケーションに広くインストー ル可能であること。 2. 失効証明書リストが公開されていること。 3. 証明書の詳細、そのシリアル番号を表示すること。 4. ユーザが証明書要求を申し込むためのフォームが用意されていること。 これらの要件は全部 web サーバとスクリプトを用いてできます。 準備中：ここに web インターフェース用のコードを入れる。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Chapter 3. アプリケーションで証明書を使う 3.1. セキュアなインターネットプロトコル 3.1.1. apache の mod_ssl で証明書を使う まず第一に、どのアプリケーションでもあなたの自己署名ルート CA 証明書を 絶対に使わないこと。特に apache では、あなたの秘密鍵のパスフレーズを削 除するように要求されるからです。 まず、www.mysite.com のような通常名(Common Name, CN)で証明書要求を作成 し書名します。 ---CERTIFICATE--- の部分だけを保存して余計な情報は削除し てください。 秘密鍵を読むときには何のパスワードも要求されませんから、鍵を非セキュア （安全でない状態）にする必要があります。あなたの秘密鍵を含む newreq.pem ファイルを取り出し、そこからパスフレーズを削除してください。 openssl rsa -in newreq.pem -out wwwkeyunsecure.pem その鍵（PRIVATE Key)は安全でないですから、あなたは自分が何をしているの かちゃんと分かっている必要があります：ファイルの許可情報をチェックする とか…もし誰かがそれを手に入れたら、あなたのサイトの信用が損なわれるこ とになります（既に警告しましたよ）。これで、apache 用に newcert と cakeyunsecure.pme が使えるようになりました。 /etc/httpd/conf/ssl/ ディレクトリの wwwkeyunsecure.pem と newcert.pem をそれぞれ wwwkeyunsecure.pem と wwwcert.crt としてコピーしてください。 /etc/httpd/conf/ssl/ssl.default-vhost.conf を編集します。 ---- # Server Certificate: # サーバの証明書： # Point SSLCertificateFile at a PEM encoded certificate. If # the certificate is encrypted, then you will be prompted for a # pass phrase. Note that a kill -HUP will prompt again. A test # certificate can be generated with `make certificate' under # built time. # PEM エンコードされた証明書で SSLCertificateFile を示す。 # もし証明書が暗号化されていれば、パスフレーズを要求されます。 # kill -HUP は再び入力を促すことに注意。ビルド時に、 # 'make certificate' としてテスト証明書を生成可能です。 #SSLCertificateFile conf/ssl/ca.crt SSLCertificateFile wwwcert.crt # Server Private Key: # サーバの秘密鍵： # If the key is not combined with the certificate, use this # directive to point at the key file. # もしこの鍵が証明書と一緒になっていなければ、この指示で # 鍵ファイルを示す。 #SSLCertificateKeyFile conf/ssl/ca.key.unsecure SSLCertificateKeyFile wwwkeyunsecure.pem ---- httpd を停止して再スタートし(/etc/rc.d/init.d/httpd stop)、全てのプロセ スが死に(killall httpd)、httpd が開始されたこと (/etc/rc.d/init.d/httpd start)を確認してください。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.1.2. IMAPS で証明書を使う “Using a certificate with POPS” の該当パラグラフを読んでください。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.1.3. POPS で証明書を使う ipop3sd の pem ファイルは証明書を生成し、秘密鍵を非セキュアにして、この 二つを合わせて /etc/ssl/imap/ipop3sd.pem を作ることで作成することができ ます。これは Mandrake 9.0 の imap rpm がそのファイルを探す場所です。同 様の手続きを imap についても用いることができ、その場合はファイルを /etc /ssl/imap/imapsd.pem とします。 CN はメイルクライアントが接続する名前（例えば、mail.xyz.org）でなくては なりません。MS-Outlook は、サーバタブ上では、受信メイルサーバ mail.xyz.org へ入り、アドバンスドタブ上では、 “このサーバが安全な接続 (SSL)を要求していること”をチェックして、接続を 995 番ポート(imaps)に変 更します。 mail.xyz.org からのその証明書を有効にするために、信用された ルート CA が MS Internet Explorer の中にインストールされていなければな りません。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.1.4. Postfix で証明書を使う 準備中 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.1.5. Stunnel で証明書を使う 準備中 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.1.6. Microsoft Key Manager で鍵を生成し署名する Microsoft Key Manager では、あなたが鍵を作りたいサーヴィス（例えば IMAP とか WWW など）を選びます。新しい鍵を生成するにはウィザードを使います。 識別名が以前に生成されている鍵と同じにならないよう注意してください。例 えば、通常名には(Common Name, CN) imap.mycompany.com などを使います。ウ ィザードは C:\NewKeyRq.txt ファイルに要求書をおきます。 Key Manager は 鍵を表示して、その鍵が署名されていないことを示して拒絶します。 このファイルを OpenSSL の /var/ssl ディレクトリに移し、 newreq.pem に名 前を変更し、例によって要求に署名します。 CA.pl -sign newcert.pem ファイルはテキストと -CERTIFICATE- セクションを含んでいます から、 Key Manager にとってはまだ適切な形式ではありません。このテキスト 部分を削除しなければなりませんが、以下がその簡単な方法です： openssl x509 -in newcert.pem -out newcertx509.pem テキストエディタを用いて -CERTIFICATE- セクション以外の部分を削除してし まうのもまた適切な手段です。 これで newcertx509.pem ファイルは -CERTIFICATE- セクションだけを含むこ とになりました。 newcertx509.pem ファイルを Key Manager が走っているコンピュータに転送し 、 Key Manager アプリケーションで鍵のアイコンを選んで、右クリックし、そ の鍵の証明書の Install をクリックして、このファイルを選び、パスフレーズ を入力します。これで鍵は完全に機能を発揮するようになりました。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.2. メイルをセキュアに 3.2.1. s/mime 証明書の生成と使用 単に証明書要求を生成して署名するだけですが、通常名 (Common Name, CN) を あなたのメイルアドレスにしてください。 さて、以下のように、あなたのメッセージ test.txt （出力は test.msg）に、 あなたの証明書 newcert.pem と鍵 newreq.pem を用いて書名してください： openssl smime -sign -in test.txt -text -out test.msg -signer newcert.pem -inkey newreq.pem これで test.msg を誰かに送れます。この方法を使って、署名入りの報告書や 、その他の署名入り文書を電子的に公開することができます。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.2.2. この証明書を MS Outlook で使うには これを pkcs12 ファイルとして Outlook に読み込む必要があります。あなたの newcert.pem と newreq.pem から pkcs12 ファイルを生成するには： CA.pl -pkcs12 "Franck Martin" (openssl pkcs12 -export -in newcert.pem -inkey newreq.pem -out newcert.p12 \ -name "Franck Martin") のようにするか、または pkecs12 ファイルと一緒に署名入り証明書も含めるた めに次のコマンドを使います： openssl pkcs12 -export -in newcert.pem -inkey newreq.pem -certfile cacert.pem \ -out newcert.p12 -name "Franck Martin" この証明書はあなたの公開鍵と秘密鍵を含んでいること、それらはパスフレー ズによって保護されているだけであることに注意してください。これはみんな の手に渡してはいけないファイルです。 MS Outlook でツールの、オプションとセキュリティのところに行き、 newcert.p12 ファイルを読み込ませるために import/export ボタン選択を選び 、エクスポート用のパスワードとデジタル ID "Franck Martin" を入力します （これは私の名前なので上の例では自分の名前を使ってください）。そして OK をクリックします。 ここでセッティングのボタンをクリックします。 MS Outlook はデフォルトの セッティングを選択したはずですから新規をクリックするだけです。デフォル トのセッティングを変更したいのでなければ、最後に OK をクリックします。 これで署名入りの e-mail を送る用意が整いました。あなたが署名入りの e-mail を送ると、宛先のユーザはあなたの公開鍵を受け取るでしょうから、あ なた宛に暗号化した e-mail を送ることが可能になります。 あなたのこの証明書は自己署名証明書（ルート CA 証明書）から発行されたも のですから、信用の径路は有効ではありません。なぜなら、アプリケーション はそのルート CA 証明書を知らないからです。このルート CA 証明書がダウン ロードされてインストールされていなければなりません。 "Internet Explorer で信用されたルート証明書として CA ルート証明書をインストールする" の章 を参照してください。 あなたはメッセージを、暗号化された署名入りメッセージまたは、平文のテキ ストメッセージとして送ることができます。この暗号化は、そのメッセージ自 身が復号に必要な全ての情報を含んでいるという意味で、実際の暗号化ではあ りません。しかし、メッセージの受信者が s/mime を解釈できない場合には、 そのメッセージが読めないという確証が得られます。 MS-Outlook XP の初期のバージョンでは証明書の有効性を確証するためにイン ターネットを検索することに注意してください。これによって e-mail が表示 されるまでに何秒かかかり、常時かオンデマンドなインターネット接続してい ないと MS-Outlook XP がタイムアウトするまでに数分がかかることになります 。問題点はこのプロセスが排他的であることで、マシン全体が MS-Outolook XP が作業を終えるまでフリーズしてしまいます。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.2.3. MS Outlook Express で証明書を使うには 準備中 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.2.4. Netscape Messenger で証明書を使うには 準備中 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.2.5. Evolution で証明書を使うには Evolution 1.0 では S/MIME を使えませんが、PGP だけは使えます。 Evolution の将来のリリースでは S/MIME を扱えるようになることが計画され ています（Evolution バグデータベースより）。しかし、ある場合には Evolution は、署名をチェックすることが出来ないにも関わらず、そのドキュ メントが署名された平文のテキストであることを認識して、正しくそれを表示 します（Evolution の初期のバージョンでは 3 つのMIME 署名型の一つを解釈 しませんでしたが、不幸にもそれは MS-Outlook が頻繁に用いるものでした。 ） ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.2.6. Balsa で証明書を使うには 準備中 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.2.7. KMail で証明書を使うには 準備中 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.3. ファイルシステムをセキュアに 3.3.1. WinCrypt WinCrypt は Microsoft crypto API を使ってファ イルの暗号化と署名を行います。また、オプションとして、署名する前に選ん だファイルまたはフォルダの zip アーカイブを作成します。これは証明書の保 存のフロントエンドを提供し、これによって、ユーザはインストールされた証 明書庫(Certificate Store)をブラウズし、証明書をインストールしたり削除し たり、 WinCrypt 署名に用いる証明書を選んだりすることができます。 証明書を作成する手続きは Microsoft Outlook と同様です。実際、同じ証明書 庫を用いていて、既にインストールされた証明書を Outlook 用に支持すること も、その逆も可能です。 Wincrypt 署名ファイル filename.sgn は以下のように署名を検証できます： openssl smime -verify -inform der -in filename.sgn -CAfile cacert.crt コンパチブルなフォーマットを用いて、OpenSSL でファイルに署名するには： openssl smime -sign -outform der -nodetach -out filename.sgn \ -signer certificate.pem -in filename.txt 署名されたファイルの構造を見るには： openssl asn1parse -inform der -in filename.sgn ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.4. コード（プログラム）をセキュアに 3.4.1. Micosoft Code プログラムやアプレットに署名して、そのコードの作成者であることを証明す ることも可能です。そのプログラムを使う人々にとっても、誰もそのコードの 中にウィルスやバックドアを挿入していない、と信用できるのは大事なことで す。コードに信用を与えるには、 Microsoft Authenticode SDK が必要です。 これは Microsoft のサイトの MSDN セクションから手に入れることができます 。 上と同様に証明書を作成しますが、通常名(Common Name, CN)は “ACME Software Cert” のようなものにします。 CA によって署名された証明書を手 に入れて、それを pkcs12 フォーマットに変換してください。 CA.pl -newreq CA.pl -sign CA.pl -pkcs12 "ACME Software Cert" newcert.p12 と名づけられたファイルができます。Windows の中で、このファ イルをクリックして証明書庫(Certificate Store)の中に移します。 これでプログラムに署名するためのこの証明書が使えるようになりました； signcode -cn "ACME Software cert" -tr 5 -tw 2 -n "My Application" \ -i http://www.acme.com/myapp/ \ -t http://timestamp.verisign.com/scripts/timstamp.dll myapp.exe このアプリケーションをインストールするかまたは走らせようとするときは、 “My Application” と言うタイトルと、上で -i オプションで与えたリンクの 場所が書かれたダイアログが現れます。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.5. IPSec IPSec は IP の最上位層のプロトコルで、インターネット上の二つのホストの 間にアドホックな暗号化接続を提供するものです。 IPSec の実装は IPv6 では 必須で、IPv4 には付け加えることが可能です。 IPSec が IPv6 の一部である と言っても、ネットワーク管理者から簡単に使えるものだということは意味し ません。 IPSec は、マシンの間で自動的に鍵を交換する仕組みを持つ難しさの ために、実装するのが簡単ではありません。 DNS が助けになりますが、これは 主流ではありませんし、よく知られた認証機関は企業での幅広い配備に対して 、適切な証明書の仕組みを未だ配布していません。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.5.1. FreeS/WAN FreeS/WAN は IPSec の、 GNU/Linux での人気の ある実装です。その最新のバージョン (1.9.7) では、X.509 を受け入れるため にパッチをあてる必要があります。このサイト に パッチをあてたバージョンがあります。 GNU/Linux のディストリビューション によってはパッチが既に適用されていますので、パッケージをチェックしてく ださい。このバージョンの利点は、FreeS/WAN と DNS CERT のために用いる証 明を生成するのに openssl を使うことができることですが、さらに具体的に言 うと IPSec の Microsoft による実装とうまく通信できるようになります。さ らなる情報については、 Nate のページ を参照してください。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.5.1.1. FreeS/WAN ゲイトウェイ あなたの IPSec ゲイトウェイ（例えば host.example.com）の完全に権限のあ るドメイン名を CN にして証明書を生成してください。証明書に署名するのを 忘れないように。二つのファイル newcert.pem と newreq.pem があることにな ります。 newreq.pem ファイルは秘密鍵と余計な情報を含みますから、秘密鍵 だけを含むように編集しておく必要があります。 --BEGIN RSA PRIVATE KEY-- と --END RSA PRIVATE KEY-- の外側を全て削除してください。ファイルをゲイ トウェイマシンの適切な場所に移してください。これを安全に行うことに気を つけて。私のディストリビューションでは、FreeS/WAN の設定ファイルは全て /etc/freeswan におかれていますが、これは状況によって異なるかもしれませ ん。 mv newreq.pem /etc/freeswan/ipsec.d/private/host.example.com.key mv newcert.pem /etc/freeswan/ipsec.d/host.example.com.pem あなたのルート証明書を FreeS/WAN の設定ディレクトリにコピーしてください 。証明書だけです。鍵はコピーしないように。 mv cacert.pem /etc/freeswan/ipsec.d/cacerts 失効証明書リストを生成し、正しい場所にコピーします。 openssl ca -genrcl -out /etc/freeswan/ipsec.d/crls/crl.pem さらにゲイトウェイマシン上で、以下の行を含めることで ipsec.secrets ファ イルを設定します： : RSA host.example.com.key “ password” 鍵対を生成したときのパスワードを入力。以下のように ipsec.conf を設定し ます： config setup interfaces=%defaultroute klipsdebug=none plutodebug=none plutoload=%search plutostart=%search uniqueids=yes conn %default keyingtries=1 compress=yes disablearrivalcheck=no authby=rsasig leftrsasigkey=%cert rightrsasigkey=%cert conn roadwarrior-net leftsubnet=/ also=roadwarrior conn roadwarrior right=%any left%defaultroute leftcert=host.example.com.pem auto=add pfs=yes お分かりのように、二つの接続が確立しています。一つはゲイトウェイマシン へ、一つはゲイトウェイマシンの背後のネットワークへ。これは、もしあなた がゲイトウェイマシン上でファイアーウォール/NAT の類を設定しているなら特 に便利です。この設定は有効な証明書を持っている人は誰でもゲイトウェイマ シンに接続できるようになっています。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.5.1.2. FreeS/WAN クライアント 手続きは同様で、クライアントマシンの完全に権限のあるドメイン名（例えば client.example.com）を CN にしてクライアントマシンの証明書を生成する必 要があります。この証明書はゲイトウェイの証明書と同じ署名機関に署名され ていなければなりません。これによって、その接続が認証されます。 ゲイトウェイのときのように、以下のファイルを安全に設定用ディレクトリに コピーします。 mv newreq.pem /etc/freeswan/ipsec.d/private/clienthost.example.com.key mv newcert.pem /etc/freeswan/ipsec.d/clienthost.example.com.pem またあなたのルート証明書も FreeS/WAN 設定ディレクトリにコピーします。証 明書のみで、鍵はコピーしないように。 mv cacert.pem /etc/freeswan/ipsec.d/cacerts 失効証明書リストを生成し、正しい場所にコピーします。 openssl ca -genrcl -out /etc/freeswan/ipsec.d/crls/crl.pem 最後にあなたのゲイトウェイマシンに証明書もコピーする必要があります（秘 密鍵はコピーしない）。 mv host.example.com.pem /etc/fresswan/ipsec.d/host.example.com.pem 同様に、クライアントの秘密鍵をロードするために ipsec.secrets ファイルを 編集します。 : RSA clienthost.example.com.key “password” そして、接続を可能にするために以下のように ipsec.conf を編集してくださ い： config setup interfaces=%defaultroute klipsdebug=none plutodebug=none plutoload=%search plutostart=%search uniqueids=yes conn %default keyingtries=0 compress=yes disablearrivalcheck=no authby=rsasig leftrsasigkey=%cert rightrsasigkey=%cert conn roadwarrior-net left=(ip of host) leftsubnet=(gateway_host_subnet)/(gateway_host_netmask) also=roadwarrior conn roadwarrior left=(ip of host) leftcert=host.example.com.pem right=%defaultroute rightcert=clienthost.example.com.pem auto=add pfs=yes これで VPN リンクを開始することができます。 ipsec auto --up roadwarrior ipsec auto --up roadwarrior-net 自動的にこのリンクを開始するためには、設定ファイルの 'auto=add' を 'auto=start' に置き換えます。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.5.1.3. MS Windows 2000/XP クライアント この手続きは FreeS/WAN クライアントと同じです。 winhost.example.com の CN で証明書を生成しますが、この証明書を .p12 ファイルに変換する必要があ ります。 “MS-Outlook で証明書を使うには” の章の手続きに従ってください 。ただし、.p12 ファイルはルート CA 証明書: winhost.example.com.p12 と一 緒にされていることを確認してください。 加えて、以下の出力に注意： openssl x509 -in cacert.pem -noout -subject このファイルを安全に MS-Windonws マシンにコピーします。 Marcus Muller 氏の ipsec.exe ユーティリティ を 、例えば c:\ipsec ディレクトリにインストールする必要があります。 コンソール (Micorsoft Management Console, MMC) を開いて、「追加/削除 ('Add/Remove Snap-in')」のところで「追加('Add')」をクリックし、「証明書 ('Certificates')」をクリックすると、「追加」で「コンピュータアカウント ('Computer Account')」を選び、そして「次('Next')」に行きます。「ローカ ルコンピュータ(Local Computer')」を選んで、「終了('Finish')」、「閉じる ('Close')」をクリックして最後に「OK」です。 これで .p12 証明書を追加できます。 プラス矢印を「証明書（ローカルコンピュータ）」でクリックして、「パーソ ナル」を右クリック、そして「全てのタスク」をクリック、そして「インポー ト」で「次」をクリックします。 .p12 ファイルへのパスをタイプし（または ブラウズしてファイルを選択し）、「次」をクリックします。エクスポート用 のパスワードをタイプして、「次」をクリックします。「証明書の種類に基づ いて自動的に証明書庫を選択」を選び、「次」をクリックします。「終了」を クリックして、ポップアップしたプロンプトに「Yes」と答えます。 MMC を終 了して、毎回 Snap In を再追加する必要がないように、ファイルとして保存し ます。 ipsecpol.exe (Windows2000) または ipseccmd.exe (Windows XP) を ipsec ユ ーティリティのドキュメントに書かれているようにインストールします。（ Windows マシン上で）ipsec.conf ファイルを編集して、 "RightCA" を 'openssl x509 -in cacert.pem -noout -subject' の出力で置き換え、以下の ようにフォーマットし直します。（以下の例に従って、 / をコンマに変え、フ ィールドの名前をいくつか変更する必要があります。）： conn roadwarrior left=%any right=(ip_of_remote_system) rightca="C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, CN=SOPAC Root" network=auto auto=start pfs=yes conn roadwarrior-net left=%any right=(ip_of_remote_system) rightsubnet=(your_subnet)/(your_netmask) rightca="C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, CN=SOPAC Root" network=auto auto=start pfs=yes リンクを開始しましょう。 'ipsec.exe' コマンドを走らせます。以下が出力の例です： C:\ipsec>ipsec IPSec Version 2.1.4 (c) 2001,2002 Marcus Mueller Getting running Config ... Microsoft's Windows XP identified Host name is: (local_hostname) No RAS connections found. LAN IP address: (local_ip_address) Setting up IPSec ... Deactivating old policy... Removing old policy... Connection roadwarrior: MyTunnel : (local_ip_address) MyNet : (local_ip_address)/255.255.255.255 PartnerTunnel: (ip_of_remote_system) PartnerNet : (ip_of_remote_system)/255.255.255.255 CA (ID) : C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, CN=SOPAC Root... PFS : y Auto : start Auth.Mode : MD5 Rekeying : 3600S/50000K Activating policy... Connection roadwarrior-net: MyTunnel : (local_ip_address) MyNet : (local_ip_address)/255.255.255.255 PartnerTunnel: (ip_of_remote_system) PartnerNet : (remote_subnet)/(remote_netmask) CA (ID) : C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, CN=SOPAC Root... PFS : y Auto : start Auth.Mode : MD5 Rekeying : 3600S/50000K Activating policy... C:\ipsec> ここで、ゲイトウェイホストに ping してみてください。 'Negotiateing IP Security'（「IP セキュリティのネゴシエーションをしています」）と二三回 表示されて、ping の応答が帰ってくるはずです。これは二三回の試行が必要か もしれないことに注意してください。 T1 からケーブルモデム上の VPN サーバ にヒットするのに、 3, 4 回の ping がかかるのが普通です。リモートエンド 上でイントラネットワークについても同じことをしてください。ちゃんとやり 遂げましょう！ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Chapter 4. グローバル PKI 4.1. 現在の PKI の状況 現在、商用の PKI とあなた自身の PKI のどちらを使うかの選択があります。 商用の PKI は最初からインターネット上でのセキュアな商取引、つまり基本的 には、セキュアな HTTP 通信を可能にするために作られました。証明書の値段 はホスト一つあたりベースで計算されています。そのコストは証明書の所有者 を特定するコスト（追跡可能性）の分、ドメイン名についてはより高価になり ますが、あなたの e-コマースの利益の割合にもよります。残念ながら、ホスト ベースのこのバージョンには大きな制限があります。これは secure POP, IMAP, その他のプロトコルへの証明書を持つことを受け入れるものの、あなた のネットワークの各メイルボックスごとに証明書が必要になると、そのコスト は天井知らずに上がり始め、認証局へのこれらの証明書の全てを登録する管理 負担も急増し、これが毎年続いていきます。クライアント/サーバ型アプリケー ションのクライアント（Web サーバ、IPSec などなど)を認証する証明書を用い るときもやはり同じ問題が生じます。 どうして他の証明書に署名できる証明書をもってはいけないのでしょうか？こ の時点での唯一のオプションとして、この文書で紹介したように、自分自身の 認証局を立ててしまうことがあります。これによって証明書の柔軟な運用が可 能になりますが、適用はあなたの組織の人々に制限されます。と言うのも、あ なたの組織に属さない人々は、スムーズな操作を可能にするために、あなたの ルート CA 証明書をロードする必要があるからです。 DNSが運用されているのと同様のフォーマットで、中央認証局によって一意の PKI 運営をするという解決法は、グローバル PKI と呼ばれています。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 4.2. グローバル PKI の必要性 最近では、個人のコンピュータのセキュリティが重要になってきていて、ビル ・ゲイツも Microsoft は機能とセキュリティのどちらかを選ぶ必要がある時は 、今やセキュリティの方を選ぶと宣言しています。 この反省はインターネット上のならず者たちの数の増加から来ています。誰で もあなたに何でも送りつけることができ、あなたのコンピュータにインストー ルするように騙すことができます。この解決策は、あなたに問題が起こったと きに、少なくとも誰かに責任を問えるように、全員の身元を識別することです 。これは SPAM については特に真実です。しばしば望まぬ e-mail を組織した 人間を見つけることも、さらに悪いことにはこの人物を止めることも困難です 。多くの人々が必要としているものが、この追跡可能性です。もしあなたが証 明書を通して追跡できない情報を受け取ったとすると、あなたはこの情報を区 別して扱うことにするかもしれません。これは電話ネットワークの呼び出し側 ID と同じ概念です。証明書はこの能力をインターネット上の全てのアプリケー ション、例えば、 e-mail (S/MIME), 商業取引(HTTPS), ソフトウェアのインス トール（コード署名）、などに与えることができます。残念ながら、証明書は 広く使われていません。と言うのも、完全に配備しなければならないとすれば 、多大のコストがかかってしまうからです。 Yahoo mail, Hotmail, CA Online の何人のユーザが e-mail 証明書を持つことができるでしょう。フリーの e-mail に証明書を提供するスキームは存在しますが、それはその e-mail アド レスが存在するという確証を与えられるだけで、現実世界にいる生身の人間ま で追跡できるわけではありません。 グローバル PKI が必要とされています。必要な全てのプロトコルと標準規格は 存在していて、新たに車輪を再発明するような必要はありません。 IETF にちゃんと働く全てのメカニズムがそろっています。 LDAP サーバが証明書を蓄え、DNS サーバが証明書庫への参照を提供し、 HTTP がアプリケーションまで証明書を運び、 S/MIME でセキュアな e-mail 通信を 可能にする…という具合です。今や、問題はポリシーの問題、または、グロー バル PKI と協調させるべきこの標準のどの部品を選ぶのか、という側面的な問 題です。どこの機関がこのようなサーヴィスを提供するのか？どれくらいの水 準のセキュリティと追跡可能性を達成するのか？もし誰かがこれらの問題に答 えられれば、正しい方向に一歩進むことになるでしょうし、ユーザがそれを受 け入れてくれれば、問題は解決されるでしょう… 著者は Internet Society の PKI ワーキンググルー プの作業の進行に沿って、この章をアップデートして行くつもりです。 Internet Society は .org トップレベルドメイン名を管理してもいますから、 この e-mail スパム問題を解決する大きな能力をその手に持っているわけです 。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Chapter 5. 日本語版謝辞 JF Project の皆さん、特に校正をしていただいたかねこ(Seiji Kaneko)さんに お礼を申し上げます。誤字・脱字・誤訳等なにかありましたら までお知らせください。