# SSL Certificates HOWTO

V0.5 20 October 2002
Franck
Martin
原
啓介
日本語訳

    kshara@mars.dti.ne.jp

v0.5
2002-10-20
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
v0.4
2002-06-22
FM
Various corrections - adding ASCII Art
v0.3
2002-05-09
FM
Adding x509v3 extension information - Correcting spelling
v0.2
2001-12-06
FM
Adding openssl.cnf file / Adding CRL info from Averroes, a.averroes@libertysurf.fr / Correcting spelling
v0.1
2001-11-18
FM
Creation of the HOWTO

認証局(CA, Certificate Authority)の運用の方法や、 安全な Web 接続、e-mail に用いるためにどう証明書を発行し、署名するか、 または、署名入りコードの作り方、その他の使い方についての、最初の入門的解説。

## 一般的知識

### イントロダクション

親愛なる読者諸氏、私と同じように OpenSSL プロジェクトの アプリケーションの man ページを熱心に読んで、 そしてまた私と同じように、 どこから始めてよいのやら、証明書がどのように安全に働いているのか、 さっぱり分からなかった、そんなあなた。 この文章があなたの質問のほとんどに対する回答です。

この HOWTO 文書では linux 用でないアプリケーションも扱います。 と言うのも、それらが使えないなら、発行したところで証明書を使えないからです。 全てのアプリケーションをリストアップしませんが、 追加の章や訂正箇所があれば私に報せてください。 私には以下のアドレスで連絡がつきます： franck@sopac.org.

この HOWTO 文書は The Linux Documentation Project において公開されたものです。ここで、この文書の最新版が得られます。 （訳者注：翻訳版は JF Project で公開されています）

#### 免責事項とライセンス

この文書は役に立つだろうとの期待から配布されていますが、 「何の保証もありません」、つまり、 そこから派生する「市場性」や「特定目的適合性」についての保証もありません。

簡単に言うと、ここで書かれているアドバイスによってあなたの 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 をハードコピーして出版するときには、 著者に「レビュー用」に何部か送ってください ;-) 私がヌードルを料理するのに何かを送ってくれるのもいいですね ;-)

#### 予備知識

イントロダクションで述べたように、この文書は手にとって使う HOWTO で、 Open SSL のソフトウェアの man ページを別途、調べてもらう必要があります。 また、セキュリティ関係の本を読んで、 どのようにセキュリティが危険にさらされるのかを学ぶべきでもあります。 証明書は通信の安全性を増加させることを目的としていますが、 あなたが行うこととの係わり合いの全てのセキュリティの問題を理解し、 セキュリティについて Open SSL にできることと、できないことを理解することは、 大変に重要です。

### 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 ドキュメントを対称鍵を用いて復号し、 その情報を表示する。

以上で理解しなくてはならない概念がいくつか出てきました。

#### 秘密鍵と公開鍵：

秘密鍵/公開鍵の鍵ペアを用いる暗号化は、 データが一方の鍵で暗号化されると、その対である他方の鍵でしか復号できない、 ということを保証します。 理解するのが難しいですが、私を信じてうまく行くことにしてください。 その鍵は自然にあるものと似ていますが、違う使い方ができます。 つまり、一方の鍵が暗号化すると、その対の鍵で復号化できるのです。 この鍵対は素数の性質に基づいていて、 それらのビット長が対の鍵なしにメッセージを復号する困難さを保証します。 鍵ペアを使う根本のアイデアは、片方の鍵を秘密にしておき（秘密鍵）、 そしてその対の他方の鍵をみんなに公開してしまう（公開鍵）ことです。 だれでもあなたに暗号化したメッセージを送ることが出来て、 あなただけがそれを復号化することが出来るのです。 あなたは対になっている他方の鍵を持っているただ一人の人なのですから。 でしょう？ この逆に、 あるメッセージが確かにあなたから来たものだと保証することもできます。 なぜなら、あなたが自分の秘密鍵で暗号化したものは、 それと対になっている公開鍵だけが正しく復号できるからです。 この場合には、メッセージは安全ではなく、 単にあなたが署名しただけだということに注意してください。 みんながその公開鍵を持っているのだということを忘れずに！

残された問題の一つは通信相手の公開鍵を知ることです。 通常は、証明書と同じく公開鍵も含まれた、 秘密でない署名入りメッセージを送ってもらうよう相手に要求します。

    Message-->[Public Key]-->Encrypted Message-->[Private Key]-->Message

#### 証明書：

自分が正しい人物、またはこの場合の方が多いでしょうが、 正しい 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-----

もうお気づきになっているように、 証明書はその発行者への参照を含んでいて、 証明書の所有者の公開鍵、証明書の有効期間と この証明書が改竄されていないことを保証するための証明書の署名が含まれています。 証明書は秘密鍵を含みません。秘密鍵はどんな形式であろうが 決して誰かに渡すべきでないからです。 この証明書は所有者に暗号化メッセージを送り、 そしてメッセージがこの証明書の所有者によって署名されていることを保証するための、 全ての情報を含んでいます。

#### 対称鍵：

ええ、秘密鍵/公開鍵暗号アルゴリズムは偉大です。しかし、 これは通常使うものとしては現実的でありません。 復号化するためには別の鍵が必要ですから、これは非対称的です。 暗号化と復号化に同じ鍵を使うことはできません。 復号化と暗号化に同じ鍵を用いるアルゴリズムは対称鍵を持つと呼ばれます。 対称なアルゴリズムは非対称なアルゴリズムよりずっと速く仕事をこなします。 しかし、対称鍵は潜在的に非常に危険です。 もし敵がその鍵を手に入れたら、あなたはもはや秘密の情報はなくなります。 ですから、敵の手に渡すことなくその鍵を相手に送らなければなりません。 ご存知のように、インターネット上には安全なものは何一つありません。 この解決策はその対称鍵を非対称アルゴリズムで暗号化したメッセージの カプセルの中に入れることです。 秘密鍵は決して誰にも渡しませんから、公開鍵で暗号化されたメッセージは安全です （正確に言えば、比較的安全です。死と税金以外に確かなものは何もないのですから）。 対称鍵はランダムに選ばれますから、 もし対称鍵が発見されても、次の通信では全く異なることになります。

    Symetric Key-->[Public Key]-->Encrypted Symetric Key-->[Private Key]-->Symetric Key

#### 暗号化アルゴリズム：

可能な暗号化アルゴリズムには、 色々な鍵の長さの、対称的なもの、非対称的なもの、と様々あります。 通常は、アルゴリズムで特許をとることはできません。 もし、ポアンカレが自分のアルゴリズムの特許をとっていたら、 アインシュタインを訴えることができたでしょう… そういうわけでアルゴリズムでは特許をとることはできません、 ただしアメリカ合衆国が主な例外です。 OpenSSL は、アルゴリズムで特許がとることができない、 そして暗号化技術が軍や情報機関のような国家機関だけに制限されてはいない 国で開発されています。 ブラウザと web サーバのネゴシエーション（プロトコルのやりとり）の間に、 その双方のアプリケーションは望ましい順番に並べた可能なアルゴリズムのリストを 見せあいます。 そして共通の望ましいアルゴリズムが選ばれます。 OpenSSL は、特定のアルゴリズムを含めたり、除いたりした形でコンパイル可能ですから、 制限が適用されている多くの国でも使えるのです。

#### ハッシュ

ハッシュ（ハッシュ値） とはハッシュ関数によってメッセージから作られたある数字のことです。 これは一方通行関数で、つまり、 そのハッシュから元のメッセージを得ることが不可能であることを意味しています。 しかし、ハッシュは元のメッセージがほんの少し変更されても劇的に変化します。 よって、そのハッシュを変えないままメッセージを変形することは非常に困難です。 ハッシュはメッセージ要約 (message digest) とも呼ばれます。 ハッシュ関数はパスワード方式の仕組みや、 アプリケーションがオリジナルであることを保証するためや（MD5 チェックサム）、 一般にはメッセージが改竄されていないことを確証するために使われます。 IETF (Internet Engineering Task Force) はいくつかの技術的な理由から MD5 より SHA1 の方が望ましいハッシュ関数であると考えているようです （RFC2459 7.1.2. と 7.1.3. を参照のこと）。

#### 署名：

メッセージに署名することは、そのメッセージの真正性をあなた自身が保証した、 ということを意味します（ほとんどの場合はあなたが著者でしょうが、 必ずしもそうでなくても構いません）。 そのメッセージは普通のテキストであったり、誰かの証明書であるという場合もあるでしょう。 あなたがメッセージに署名するためには、 まずメッセージのハッシュを作成し、あなたの秘密鍵によってそのハッシュを暗号化して、 その暗号化されたハッシュと署名された証明書をメッセージに添付します。 これを受け取った方は、 メッセージのハッシュを独立に再び作成し、 あなたの署名入りの証明書から取り出したあなたの公開鍵で復号化して元のハッシュを得て、 この二つのハッシュが等しいかどうかをチェックし、 最後に証明書をチェックします。

メッセージに署名する他の利点は、 全ての受け取り手に対して自動的に公開鍵と証明書を送ることになることです。

通常、署名には二通りの方法があります。 署名の中にテキストメッセージを（区切り指定文字を入れて）カプセル化する形式と、 メッセージを署名と一緒にコード化してしまう方法です。 後の形式は非常に単純な暗号化で、 埋め込まれた公開鍵を読めればどんなソフトウェアでも復号できます。 最初の形式の利点は、メッセージが人間に読むことができて、 それを読むユーザへとメッセージを渡すクライアントに何の問題も生じない一方、 二番目の形式ではメッセージが改竄されていると、 メッセージの一部を読むことさえできないことです。

#### パスフレーズ：

“パスフレーズはパスワードより長いという以外にはパスワードと 同じようなものです”。 初期には Unix システムでのパスワードは８文字までに限られていたので、 より長いパスワードをパスフレーズと言うのです。 パスワードが長ければ長いほど、推測するのが難しくなります。 現在の Unix システムでは MD5 を使うことで、 パスワードの長さの制限はなくなっています。

#### 公開鍵基盤 (PKI, Public Key Infrastracture)

公開鍵基盤(PKI, Public Key Infrastructure)とは、 証明書に署名し、無効になった証明書のリストを維持し、公開鍵を配布するといったことを 可能にするためのソフトウェアとデータベースのシステムのことです。 通常は、web サイトか ldap サーバ、またはその両方を通じてこれにアクセスします。 そこでは誰かが、あなたが本当にあなたであることをチェックしていることになるでしょう。 個々のアプリケーションの安全性を高めるには、 良く知られた商用の PKI を用いることができます。 これは、おそらくその root CA の証明書が、 ブラウザやアプリケーションに既に組み込まれているからです。 問題点は、安全に e-mail を使いたい場合で、 あなたは e-mail の一般的なタイプの証明書を手に入れるか、 または証明書/e-mail ごとに一年あたり約 100 USドルを払わなくてはなりません。 もし、以前に（公開鍵を含んだ）証明書つきの e-mail を一度も受け取っていないと、 誰かの公開鍵を見つける方法もありません。

### S/MIME その他のプロトコルってどんなもの？

SSL は web サーバのために開発されたので、 任意のプロトコルを暗号化するために用いることが可能です。 どんなプロトコルでも SSL の中にカプセル化できます。 この方法は IMAPS, POPS, SMTPS, ... などで用いられています。 これらの安全性を高めたプロトコルは、 その安全でないバージョンとは異なるポート番号を使っています。 また、SSL はどんな通信を暗号化するのにも使えます。 通信相手と直接の（即時の）接続をする必要はありません。 S/Mime はそんなプロトコルで、通常の e-mail の内側に、 暗号化したメッセージをカプセル化するのです。 メッセージは受け取る相手の公開鍵で暗号化されます。 あなたは web サイトか、レポジトリから公開鍵を手に入れるか、 または公開鍵と証明書を e-mail で送ってもらうように相手に要求します （証明書は本当に正しい相手に話しかけているか保証するためです）。

逆の順序で、ブラウザは自分自身の署名された証明書を、 身元確認用としてweb サーバに送ることができます。 しかし、ブラウザの証明書は誰でも CA web サイトで手に入れることができます。 そうです、しかし送られてきた証明書は秘密鍵で暗号化されていて、 その公開鍵でしか復号できません。

## 証明書の運用

### インストール

今では、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 以下におかれています。

#### 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";

#### 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 が使える。

- このファイルは変数の &lsqb;セクション&rsqb; で構成されている。

dir:

  ベースになるディレクトリを特定する。

default_ca:

  どのセクションがデフォルトの証明書についての変数を含むか特定する。

basicConstraints:

  証明書の使い方を定義する。例えば、CA:TRUE は、 その証明書が root CA 証明書であること。

#### 認証局を作る

認証局を作るには、正確に openssl.cnf を編集したのち、以下のコマンドを使います：

    CA.pl -newca

このユーティリティはあなたの CA 証明書として発効させる証明書ファイルを選ぶか、 または新たに作るように尋ねてきます。 練習のために以下の手順に従って一つ作ってみましょう。 次の章では、このデフォルトで作成された CA を上書きして、 もっと長く使える新しいものを作成します。 CA.pl は 365 日間の証明書だけしか作ってくれません。

### ルート認証局証明書を作る

    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 証明書を信用してもらって、 これをダウンロードし、ブラウザに登録してもらう必要があります。

この証明書で他の証明書に署名したいときにはその都度、パスフレーズをタイプ しなければなりません。

### 非ルート認証局証明書を作る

この手続きについてはまだ確信がないので、間違いがあったら訂正してください。

それが有効で、署名能力を与えられて発行されている限り、 勝手な署名入り証明書を使って、他の証明書に署名することは可能です。 ですから、証明書要求と秘密鍵を作り、 第三者によって証明書に署名してもらい、 署名入り証明書と秘密鍵をインストールすることができます。 -PRIVATE KEY- の部分は private/cakey.pem ファイルに入り、 -CERTIFICATE- の部分は cacert.pem に入ります。

### 信用が与えられたルート証明書として 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 の将来のリリースに入れてくれるかもしれません。

#### Netscape/Mozilla では

Netscape を用いて、web サーバかファイルシステムから 証明書をダウンロードしてください。 Netscape は、それがルート証明書であることを自動的に認識し、 それを保存するように促すでしょう。 ウィザードに従って証明書をインストールしてください。 ウィザードの最後に、この証明書を信用するアプリケーションのタイプはどれか 特定しなければなりません： web サイトセキュリティ、e-mail 署名、コード署名などです。

#### Galeon では

Galeon は Mozilla と同じ HTML レンダリングエンジンを用いているので、 Mozilla と似た動作をします。 しかし、Galeon には証明書を扱うツールは含まれていません。

#### Opera では

準備中。

#### Internet Explorer では

ブラウザで証明書のアドレスをクリックして、ディスクにファイルを保存してください。 ファイルをダブルクリックすると証明書インストールウィザードが立ち上がります。 この証明書は自己署名されていますから、Internet Explorer は信用された ルート認証局として自動的にインストールします。 以降は、Internet Explorer は文句を言わず、 ルート CA 証明書によって署名された証明書も同様に信用するでしょう。

Internet Explorer から証明書を表示させることもできます。 インストール証明書のボタンをクリックすると、 証明書インストールウィザードが立ち上がります。

### 証明書の運用

#### 証明書要求の生成と署名

    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- セクションを要求してください。

#### 証明書の破棄（無効化）

証明書を破棄（無効化）するには単純に以下のようなコマンドを命令します：

    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

#### 証明書の更新

ユーザはあなたにその古い証明書要求を送り、 その秘密鍵に基づいて新しいものを作成します。

まずあなたは、以前の証明書を破棄（無効化）し、再び証明書要求に署名しなければなりません。

古い証明書を見つけるには、要求に対応したその識別名 (Distinguished Name, DN) を index.txt ファイルの中で探します。 シリアル番号 <xx> を得て、破棄手続きのための証明書として cert/<xx>.pem ファイルを用いてください。

新しい証明書の有効期間の開始日と終了日を正しく設定する必要がありますから、 以下のように手動で証明書に署名しましょう。

    openssl ca -config /etc/openssl.cnf -policy policy_anything -out newcert.pem \
    -infiles newreq.pem -startdate [now] -enddate [previous enddate+365days]

&lsqb;now&rsqb; と &lsqb;previous enddate+365days&rsqb; を 正しい値で置き換えてください。

#### 証明書の表示

コード化された形式で証明書を保存しているかも知れませんが、 その場合、証明書の詳細を実際に読むには以下のコマンドを使います：

    openssl x509 -in newcert.pem -noout -text

#### index.txt ファイル

index.txt の中には OpenSSL によって運用される様々な証明書があります。 各エントリは破棄されたもの(Revoked)には R, 有効なもの(Valid)には V, 期限切れのもの(expired)には E と印しがつけられています。

#### web ベースの認証局を立ち上げる

あなたが認証局(CA)であるためには以下のような若干の要件があります：

1. ルート CA 証明書が公開されており、 アプリケーションに広くインストール可能であること。

2. 失効証明書リストが公開されていること。

3. 証明書の詳細、そのシリアル番号を表示すること。

4. ユーザが証明書要求を申し込むためのフォームが用意されていること。

これらの要件は全部 web サーバとスクリプトを用いてできます。

準備中：ここに web インターフェース用のコードを入れる。

## アプリケーションで証明書を使う

### セキュアなインターネットプロトコル

#### 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)を確認してください。

#### IMAPS で証明書を使う

“Using a certificate with POPS” の該当パラグラフを読んでください。

#### 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 の中に インストールされていなければなりません。

#### Postfix で証明書を使う

準備中

#### Stunnel で証明書を使う

準備中

#### Microsoft Key Manager で鍵を生成し署名する

Microsoft Key Manager では、あなたが鍵を作りたいサーヴィス （例えば IMAP とか WWW など）を選びます。 新しい鍵を生成するにはウィザードを使います。 識別名が以前に生成されている鍵と同じにならないよう注意してください。 例えば、通常名には(Common Name, CN) imap.mycompany.com などを使います。 ウィザードは C:&bsol;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 をクリックして、 このファイルを選び、パスフレーズを入力します。 これで鍵は完全に機能を発揮するようになりました。

### メイルをセキュアに

#### 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 を誰かに送れます。 この方法を使って、署名入りの報告書や、 その他の署名入り文書を電子的に公開することができます。

#### この証明書を 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 が作業を終えるまでフリーズしてしまいます。

#### MS Outlook Express で証明書を使うには

準備中

#### Netscape Messenger で証明書を使うには

準備中

#### Evolution で証明書を使うには

Evolution 1.0 では S/MIME を使えませんが、PGP だけは使えます。 Evolution の将来のリリースでは S/MIME を扱えるようになることが 計画されています（Evolution バグデータベースより）。 しかし、ある場合には Evolution は、 署名をチェックすることが出来ないにも関わらず、 そのドキュメントが署名された平文のテキストであることを認識して、 正しくそれを表示します （Evolution の初期のバージョンでは 3 つのMIME 署名型の一つを解釈しませんでしたが、 不幸にもそれは MS-Outlook が頻繁に用いるものでした。）

#### Balsa で証明書を使うには

準備中

#### KMail で証明書を使うには

準備中

### ファイルシステムをセキュアに

#### 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

### コード（プログラム）をセキュアに

#### 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 オプションで与えたリンクの場所が書かれたダイアログが現れます。

### IPSec

IPSec は IP の最上位層のプロトコルで、 インターネット上の二つのホストの間にアドホックな暗号化接続を提供するものです。 IPSec の実装は IPv6 では必須で、IPv4 には付け加えることが可能です。 IPSec が IPv6 の一部であると言っても、 ネットワーク管理者から簡単に使えるものだということは意味しません。 IPSec は、マシンの間で自動的に鍵を交換する仕組みを持つ難しさのために、 実装するのが簡単ではありません。 DNS が助けになりますが、これは主流ではありませんし、 よく知られた認証機関は企業での幅広い配備に対して、 適切な証明書の仕組みを未だ配布していません。

#### FreeS/WAN

FreeS/WAN は IPSec の、 GNU/Linux での人気のある実装です。 その最新のバージョン (1.9.7) では、X.509 を受け入れるためにパッチを あてる必要があります。 このサイトに パッチをあてたバージョンがあります。 GNU/Linux のディストリビューションによってはパッチが既に適用されていますので、 パッケージをチェックしてください。 このバージョンの利点は、FreeS/WAN と DNS CERT のために用いる 証明を生成するのに openssl を使うことができることですが、 さらに具体的に言うと IPSec の Microsoft による実装と うまく通信できるようになります。 さらなる情報については、 Nate のページ を参照してください。

##### 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=<your_subnet>/<your_netmask>
    also=roadwarrior

    conn roadwarrior
    right=%any
    left%defaultroute
    leftcert=host.example.com.pem
    auto=add
    pfs=yes

お分かりのように、二つの接続が確立しています。 一つはゲイトウェイマシンへ、一つはゲイトウェイマシンの背後のネットワークへ。 これは、もしあなたがゲイトウェイマシン上でファイアーウォール/NAT の類を 設定しているなら特に便利です。 この設定は有効な証明書を持っている人は誰でもゲイトウェイマシンに 接続できるようになっています。

##### 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' に置き換えます。

##### 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:&bsol;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 がかかるのが普通です。 リモートエンド上でイントラネットワークについても同じことをしてください。 ちゃんとやり遂げましょう！

## グローバル PKI

### 現在の PKI の状況

現在、商用の PKI とあなた自身の PKI のどちらを使うかの選択があります。 商用の PKI は最初からインターネット上でのセキュアな商取引、つまり基本的には、 セキュアな HTTP 通信を可能にするために作られました。 証明書の値段はホスト一つあたりベースで計算されています。 そのコストは証明書の所有者を特定するコスト（追跡可能性）の分、 ドメイン名についてはより高価になりますが、 あなたの e-コマースの利益の割合にもよります。 残念ながら、ホストベースのこのバージョンには大きな制限があります。 これは secure POP, IMAP, その他のプロトコルへの証明書を持つことを 受け入れるものの、あなたのネットワークの各メイルボックスごとに 証明書が必要になると、そのコストは天井知らずに上がり始め、 認証局へのこれらの証明書の全てを登録する管理負担も急増し、 これが毎年続いていきます。 クライアント/サーバ型アプリケーションのクライアント （Web サーバ、IPSec などなど)を認証する証明書を用いるときもやはり同じ問題が生じます。

どうして他の証明書に署名できる証明書をもってはいけないのでしょうか？ この時点での唯一のオプションとして、この文書で紹介したように、 自分自身の認証局を立ててしまうことがあります。 これによって証明書の柔軟な運用が可能になりますが、 適用はあなたの組織の人々に制限されます。 と言うのも、あなたの組織に属さない人々は、 スムーズな操作を可能にするために、 あなたのルート CA 証明書をロードする必要があるからです。

DNSが運用されているのと同様のフォーマットで、 中央認証局によって一意の PKI 運営をするという解決法は、 グローバル PKI と呼ばれています。

### グローバル 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 スパム問題を解決する大きな能力をその手に持っているわけです。

## 日本語版謝辞

JF Project の皆さん、特に校正をしていただいた かねこ(Seiji Kaneko)さんにお礼を申し上げます。 誤字・脱字・誤訳等なにかありましたら <JF@linux.or.jp> までお知らせください。