<!--Building a Secure RedHat Apache Server HOWTO-->安全な RedHat Apache サーバの構築方法 <author>Richard Sigle, <tt/Richard.sigle@equifax.com/ <date>0.1, 2001-02-06 <trans>KURASHIKI Satoru (<tt><htmlurl url="mailto:ouka@fx.sakura.ne.jp" name="ouka@fx.sakura.ne.jp"></tt>) <tdate>0.1J, 2002-02-22 <abstract> <!-- The guide is designed to explain how PKI and SSL work together. It is essential to understand how the SSL protocol works to successfully deploy a secure server. --> このガイドは、PKI と SSL を一緒に動かす方法を説明するように 意図されています。安全なサーバを構築するためには、SSL プロトコルがどう機能して いるかを理解する必要があります。 </abstract> <toc> <!-- Begin the document --> <sect><!--Purpose/Scope of this Guide-->このガイドの目的/範囲 <p><!--The purpose of this guide is to assist RedHat Linux users with the installation of server (SSL) certificates using the Apache web server. The goal is to provide a clear procedure that will save time and, in many cases, money! --> このガイドの目的は、RedHat Linux のユーザが Apache ウェブサーバを使って サーバ(SSL)証明書をインストールするのを手助けすることです。目標は、 時間と、多くの場合お金を節約してくれる手順をはっきり示すことです！ <p><!--First, I will cover what you need to know about the SSL protocol and digital certificates. In my experience, building an Apache web server with ModSSL and OpenSSL is the most beneficial software combination. OpenSSL is a general-purpose cryptography library that supports the SSL v2/v3 and TLS v1 protocols. ModSSL is an Apache API module designed to act as an interface between Apache and OpenSSL. The biggest advantage is that all three packages are free. --> 最初に、 SSL プロトコルとデジタル証明書について知っておくべきことを 説明します。私の経験では、ModSSL と OpenSSL を使って Apache ウェブサーバを 構築するのが、最も有益なソフトウェアの組み合わせです。OpenSSL は汎用的な 暗号化ライブラリで、SSL v2/v3 と TLS v1 プロトコルをサポートしています。 ModSSL は、Apache API モジュールで、Apache と OpenSSL 間のインターフェイス として動作するように作られています。最大の利益は、これら 3 つのパッケージが フリーであることです。 <p><!--Then, beginning with Section 4, I will go through the step-by-step procedures for generating keys and installing certificates on a RedHat-Apache server compiled with ModSSL and OpenSSL. The procedures in Section 4 will also work with commercial SSL-server packages such as Stronghold and Raven that are closely related to Apache.--> そして 4 章からは、鍵の生成と、ModSSL と OpenSSL を組みこんでコンパイルされた RedHat-Apache サーバへの証明書のインストールを順を追って見ていきます。 4 章の手順は、Apache と密接に関係している Stronghold や Raven といった 商用 SSL サーバのパッケージにも適用できるでしょう。 <p><!--Disclaimer: I am a technical support engineer for Equifax Secure Inc., a Certificate Authority. Therefore, I use Equifax Secure certificates and examples geared towards installing Equifax Secure certificates. However, the instructions will also work with certificates issued by other Certificate Authorities. Since this document was written at my own initiative, Equifax Secure Inc. is neither liable nor accountable for any consequences resulting from the use of these procedures. --> 警告：私は、Equifax Secure Inc. という証明書発行機関のテクニカルサポート 技術者です。ですから、私は Equifax Secure の証明書を使いますし、例は Equifax Secure の証明書をインストールに適合した形になっています。とはいえ、 手引きは他の証明書発行機関による証明書にも使えるはずです。 この文書を私が率先して書いたからといっても、Equifax Secure Inc. は、 これらの手順を使うことによって生じる何如なる結果についても、 義務も責任も負いません。 <nidx>(your index root)!introduction</nidx> <!-- here introduction is a sub entry of template, exclamationmark is separator --> <!-- ここで、introduction は、テンプレートのサブエントリで、 エクスクラメーションマークはセパレータです。 --> <!--nakano nidx というのは索引付けのための sgml コマンドで、 まあこの説明も書かなくていいんでしょう --> <em><!--My comments to the reader is in this style (emphasized)-->読者に対する私のコメントは、このスタイル(強調)です。</em>. <tt><!--Example lines are in plain roman style-->例は普通のスタイルで示します。</tt>. <em><!--Note that extra comments and advice is found in comments within the SGML source.-->高度なコメントやアドバイスは、SGML ソース中のコメント として書いてあります。</em> <!-- such as this comment --> <!--このコメントのように--> <sect1><!--About Secure Sockets Layer (SSL)-->Secure Sockets Layer (SSL) について <p><!-- SSL is a presentation layer service, located between the TCP and the application layer. It is platform and application independent. SSL is responsible for the management of a secure communications channel between the client and server. SSL provides a strong mechanism for encrypting data transferred between a client and a server. --> SSL は、TCP とアプリケーション層の間にある、プレゼンテーション層のサービスです。 これはプラットフォームやアプリケーションには依存しません。 SSL はクライアントとサーバ間のセキュアな通信チャネルを管理する役目を持っています。 SSL はクライアントとサーバ間で転送されるデータを暗号化する、 強力な機構を提供します。 <sect1><!--FeedBack-->フィードバック <p><!--Comments on this guide may be directed to the author (<tt/richard.sigle@equifax.com/).--> このガイドについてのコメントは、著者 (<tt/richard.sigle@equifax.com/) にあてにお願いします。 <sect1><!--Copyrights and Trademarks-->著作権と商標 <p> Copyright (c) 2001 by Richard L. Sigle <p> Please freely copy and distribute this document in any format. It's requested that corrections and/or comments be forwarded to the document maintainer. You may create a derivative work and distribute it provided that you: <itemize> <item>Send your derivative work (in the most suitable format such as sgml) to the <url url="http://www.LinuxDoc.org/" name="LDP"> (Linux Documentation Project) or the like for posting on the Internet. If not the LDP, then let the LDP know where it is available. </item> <item>License the derivative work with this same license or use GPL. Include a copyright notice and at least a pointer to the license used. </item> <item>Give due credit to previous authors and major contributors. </item> </itemize> <p> If you're considering making a derived work other than a translation, it's requested that you discuss your plans with the current maintainer. <nidx>(your index root)!news on</nidx> <sect1><!--Acknowledgements and Thanks-->謝辞 <p> <!--I would like to thank Tony Villasenor for tirelessly reading my drafts and offering his input and advice. Without Tony, this document would never have been finished.--> 倦むことなく私のドラフトを読んで、アドバイスをくれた Tony Villasenor に感謝を。 Tony がいなければ、この文書は書き上げることができなかったでしょう。 <sect><!--Introduction to Secure Sockets Layer/Private Key Infrastructure--> Secure Sockets Layer/Private Key Infrastructure への招待 <p> <!-- PKI is an <em>asymmetric key system</em> which consists of a public key (which is sent to clients) and a private key (stays local on the server). PKI differs from a <em>symmetric key system</em> in which both the client and server use the same key for encryption/decryption. --> PKI は、公開鍵 (クライアントに送られます) と秘密鍵 (サーバ上に存在します) からなる、<em>非対称の鍵システム</em>です。PKI は、クライアントとサーバの両方が 暗号化/復号化に同じ鍵を使う、<em>対称の鍵システム</em>とは異なります。 <sect1><!--Responsibilities of SSL/PKI-->SSL/PKI の信頼性 <p> <!-- SSL sets out to fulfill requirements that make it acceptable for use in the transmission of even the most sensitive of transactions, such as credit card information, medical records, legal documents, and e-commerce applications. Each application can choose to utilize some or all of the following criteria depending on the sensitivity and value of the transactions it will be processing. --> クレジットカード情報や医療記録、法律文書、e-commerce アプリケーションといった、 最も機密に注意しなければならない処理の通信にも利用可能であるように、 という要求を満たすために SSL は設計されました。 各アプリケーションは、機密性や処理される取引の価値によって、 以下の特徴のどれを (あるいはすべてを) 使うか選択できます。 <descrip> <!-- <tag>Privacy</tag> Let's say that a message is to be coded for transmission from A to B. A uses B's public key to encrypt the message. In this way B will be the only person who can decode and read this message using his private key. We cannot however be sure that A is the person who he claims to be. --> <tag>プライバシー</tag> 例えば、A から B へ伝達するために、メッセージが 符号化されるとします。A は B の公開鍵を使ってメッセージを暗号化します。 こうすると、B は自分の秘密鍵を使ってこのメッセージを復号化して読むことができる 唯一の人物となります。しかし、A が自称している通りの人物であるかは定かでは ありません。 <!-- <tag>Authenticity</tag> In order to be sure that A is the person who he claims to be, we want guaranteed authenticity. This requires a slightly more complex coding process. In this case, A's message to B is first encrypted with A's private key and then with B's public key. B now has to decrypt it first with his private key and then with A's public key. Now B can be sure that A is who he claims to be as nobody else could create a message encrypted with his private key. SSL achieves this with the use of certificates (PKI). A certificate is issued by a <em>neutral</em> third party - such as a certificate authority (CA) - and includes a digital signature and/or a time stamp in addition to the public key of the certified party. A self-signed digital certificate can be created by anyone with the correct SSL tools, but self-signed certificates lack the weight of validation performed by a mutually respected neutral third party. --> <tag>認証</tag> A が自称している通りの人物であることを確かめるためには、 保証された認証が必要です。これには少しばかり複雑な暗号化の過程が必要です。 この場合、A から B へのメッセージは、最初に A の秘密鍵で、次に B の 公開鍵で暗号化されます。B はまず自分の秘密鍵で、ついで A の公開鍵で 復号化しなければなりません。これで、B は A が自称している通りの人物だと 確信できます。他の人は誰も A の秘密鍵で暗号化した メッセージを作ることはできないのですから。 SSL はこれを、証明書 (PKI) を使うことで達成しています。証明書は、 − 証明書発行機関 (CA)のような − <em>中立の</em>サードパーティから 発行され、証明された相手の公開鍵に加えて、デジタル署名やタイムスタンプを 含んでいます。正しい SSL ツールを使えば誰でも自署した デジタル証明書を作成できますが、自署した証明書では、 共通に敬意を払われている中立のサードパーティが行う、批准の 重みに欠けます。 <!-- <tag>integrity</tag> In SSL, integrity is guaranteed by using a MAC (Message Authentication Code) with the necessary hash table functions. Upon generation of a message, the MAC is obtained by applying a hash function and the result is then added to the message. After the message has been received, validity is then checked by comparing the message's embedded MAC with a new MAC computed from the received message. This would immediately reveal messages that have been altered by a third party. --> <tag>無謬性</tag> SSL においては、MAC (Message Authentication Code: メッセージ認証コード) を必須のハッシュテーブル関数とともに使うことで 無謬性が保証されています。メッセージの生成時に、ハッシュ関数を使うことで MAC が得られ、 その結果がメッセージに追加されます。メッセージが受信されると、メッセージに 埋めこまれた MAC を受けとったメッセージから計算した新しい MACと比較する ことで、妥当性が検証されます。これで、第三者によって変更された メッセージはすぐに明らかになります。 <!-- <tag>Non-Repudiation</tag> Non-repudiation protects both parties from each other during online transactions. It prevents one or the other from saying that they did not send a particular piece of information. Non-repudiation does not allow either party to alter the transaction after it has been made. Digital non-repudiation is the equivalent of signing a contract, in the traditional sense. --> <tag>否認防止</tag> 否認防止は、オンラインのやりとりの間、両方の通信者を お互いから保護します。これは、どちらかが、情報のうち特定の一部分を送らなかった、と言うのを防ぎます。否認防止は、どちら側についても、既になされたやりとりの 内容を改変することを許しません。デジタル否認防止は伝統的な感覚でいえば、 契約書にサインするのと等価です。 </descrip> <sect1><!--How SSL Works-->SSL はどう機能するのか <p> <!-- The SSL protocol includes two sub-protocols: the SSL record protocol and the SSL handshake protocol. The SSL record protocol defines the format used to transmit data. The SSL handshake protocol involves using the SSL record protocol to exchange a series of messages between an SSL-enabled server and an SSL-enabled client when they first establish an SSL connection. This exchange of messages is designed to facilitate the following actions: --> SSL プロトコルは、2 つのサブプロトコルを含みます − SSL レコードプロトコルと SSL ハンドシェイクプロトコルです。SSL レコードプロトコルはデータの伝送に使う フォーマットを定義します。SSL ハンドシェイクプロトコルには、 SSL レコードプロトコルの利用が含まれています。 これは SSL 化されたサーバとクライアントが最初に SSL 接続を確立するときに やりとりする一連のメッセージ交換に用いられます。 このメッセージ交換は、以下の機能を容易にするべく設計されています。 <itemize> <item> <!-- Authenticate the server to the client. The server certificate is signed by a Certificate Authority to insure that it is not corrupted and establishes a <em>chain of trust</em>. --> サーバからクライアントへの認証。サーバ証明書は、証明書発行機関によって 署名されており、証明書が壊れておらず、<em>信頼の鎖</em>が成立していることを 保証します。 </item> <item> <!-- Allow the client and server to select the cryptographic algorithms, or ciphers, that they both support. --> クライアントとサーバが、双方がともにサポートしている暗号化アルゴリズム、 つまりサイファー(cipher)を選べるようにします。 <!--nakano 難しいですが、やっぱり「サイファー (cipher)」程度では ないかと思います --> </item> <item> <!-- Optionally authenticate the client to the server. --> 任意で、サーバに対してクライアントを認証。 </item> <item> <!-- Use public-key encryption techniques to generate shared secrets. --> 共有の秘密を生成するのに、公開鍵暗号技術を使います。 </item> <item> <!-- Establish an encrypted SSL connection. --> 暗号化された SSL 接続を確立します。 </item> </itemize> <sect2><!--SSL Handshake Protocol-->SSL ハンドシェイクプロトコル <p><!-- The Handshake Protocol is used to co-ordinate the state of the client and the server. During the handshake, the following events take place: --> ハンドシェイクプロトコルは、クライアントとサーバの状態を調整するのに 使われます。ハンドシェイクの間、以下のイベントが発生します − <itemize> <item> <!-- Certificates are exchanged between the client and server (asymmetric keys). The server sends its public key to the client. If the server is set to verify client authentication via a certificate, the client sends its public key to the server. The validity dates on the certificates are verified and they are checked for the digital signature of a trusted certificate authority. If the validity date and/or digital signature are not correct, the browser will issue a warning to the user. The user is then given the option to trust the certificate holder. --> クライアントとサーバの間で証明書が交換されます (非対称の鍵)。 サーバは公開鍵をクライアントに送ります。サーバが証明書を使ってクライアントの 認証を行うよう設定されているなら、クライアントは公開鍵をサーバに送ります。 証明書の有効期限日を確認し、信頼された証明書発行機関のデジタル署名をチェック します。有効期限日やデジタル署名が間違っていれば、ブラウザはユーザに警告を 出します。ユーザはそれから証明書の保持者を信頼することもできます。 </item> <item> <!--The client then generates a random key (symmetric key). These will be used for encryption and for calculating MACs. They are encrypted using the server's public key and sent to the server. Only the server has the ability to decrypt the new random key. The new symmetric key is used for encrypting the data that is sent between client and server. <p>Note: The use of a symmetric key after server-browser authentication greatly enhances subsequent throughput performance.--> 次にクライアントはランダムな鍵 (対称鍵) を生成します。これらは暗号化と MAC の計算に使われます。この鍵は、サーバの公開鍵で 暗号化され、サーバに送られます。この新しい対称鍵は、サーバのみが 復号化できます。新しい対称鍵は、クライアントとサーバ間で送られるデータの 暗号化に使われます。 <p>注： サーバ - ブラウザ間認証の後に対称鍵を使うことで、その後の 処理パフォーマンスが大幅に改善されます。 </item> <item> <!--A message encryption algorithm and a hash function for integrity are negotiated. This negotiation process could be carried out such that the client presents a list of supported algorithms to the server, which, in turn, selects the strongest cipher available to both of them. Identifiers for the chosen encryption algorithm and hash function are stored in the cipher spec field of the current state for use by the record protocol.--> メッセージの暗号化アルゴリズムと、無謬性のためのハッシュ関数とが交渉 (negotiate) されます。 <!--nakano さっきは integrity が「完全さ」でしたが、統一する方が良いかと kurashiki 術語らしさを出すために「無謬性」で統一しました--> この調整過程は、クライアントがサポートしているアルゴリズムの一覧をサーバに 示し、次にサーバが双方で利用可能な最も強い暗号を選ぶ、というように実行されます。 選択された暗号化アルゴリズムとハッシュ関数の識別子は、現在のステータスの 暗号方法スペックフィールドに保存され、レコードプロトコルから利用されます。 <!--nakano 結局いまいちですけど.. --> </item> <item> <!--All of the following fields are set during handshaking: Protocol Version, Session ID, Cipher Suite, Compression Method and two random values ClientHello.random and ServerHello.random.--> 以下のフィールドは全て、ハンドシェイクの間にセットされます − プロトコルのバージョン、セッション ID、暗号の組、圧縮方法、それから 2 つのランダム値 ClientHello.random と ServerHello.random。 </item> </itemize> <p><bf><!--Note:-->注：</bf> <!-- An IP address is required for each SSL connection. Name based virtual hosts are resolved during the application layer. Remember Secure Sockets Layer resides below the application layer.--> IP アドレスは、各 SSL 接続毎に必要になります。 名前ベースのヴァーチャルホストはアプリケーション層で解決されます。 SSL がアプリケーション層の下に存在していることを思い出しましょう。 <sect2><!--Session Key(Symmetric Code)-->セッション鍵 (対称鍵) <p> <itemize> <item><!--40-bit, originally used only for export purposes--> 40 ビットは、もともと輸出用のものでした <!--米国の暗号制限関係のことだと思われます > export --> <item><!--56-bit, used by DES-->56 ビットは DES で利用されています <item><!--64-bit key - used by CAST, 256 times stronger than 56-bit-->64 ビット鍵 − CAST で利用されており、56 ビットより 256 倍強力です <item><!--80-bit key - used by CAST, 16 million times stronger than 56-bit (infeasible to break with current technology)--> 80 ビット鍵 − CAST で利用されており、56 ビットの 16,000,000倍強力です (現在の技術では、破ることはできません) <item><!--128-bit key - used by CAST or RC2, exhaustive key search impossible now and for the foreseeable future--> 128 ビット鍵 − CAST や RC2 で使われており、現在も、予測できる未来においても、網羅的に鍵を解読することは不可能です </itemize> <sect2><!--Public/Private Key Pair(Asymmetric Code)-->公開/秘密鍵のペア(非対称コード) <p> <itemize> <item>512-bit <item>768-bit <item>1024-bit <item>2048-bit </itemize> <sect1><!--How PKI Works--> PKI の仕組み <p> <!--The client and the server each have a public key and a private key (the client's browser randomly creates a key pair for the SSL session, unless, a client certificate is held by the client and requested by the server).--> クライアントとサーバは、それぞれ公開鍵と秘密鍵を持ちます (クライアントが 自分の証明書を持っており、それがサーバに要求されない限り、クライアントの ブラウザは SSL のセッション用に鍵のペアをランダムに生成します)。 <p> <!--The sender uses their private key to encrypt a message. This act authenticates the source of the message. The resulting cipher is encrypted once more with the receiving party's public key. This action provides confidentiality because only the receiving party is able to do the initial decryption of the message using their private key. The receiver uses the sender's public key to further decrypt the encrypted message. Because only the sender has access to their private key, the receiver is assured that the encrypted message originated from the sender.--> 送信者は、自分の秘密鍵を使ってメッセージを暗号化します。これにより、 メッセージのソースが認証されます。結果の暗号は、受け手の公開鍵で もう一度暗号化されます。これは、受け手のみが、自身の秘密鍵を使ってメッセージを 最初に解読することができるようにすることで、機密性をもたらします。 受信者は、暗号化されたメッセージをさらに解読するため、送信者の公開鍵を 使います。送信者のみが自分の秘密鍵にアクセスできるので、受信者は 暗号化されたメッセージがその送信者からのものであるということを保証されます。 <p> <!--A message digest is used to verify that neither party or a third party has tampered with or changed the message in any way. A message digest is obtained by applying a hash function (part of the private key known as the fingerprint) to the message. The digest (which is now known as the signature) is attached or appended to the message. The signature's length is constant (no matter how large the file is) and depends on what type of message digest the private key contains (md5 - 128 bit, sha1 - 160 bit, etc). Changing even one bit in the message will change the length of the signature and thus prove that the message has been tampered with.--> メッセージダイジェストは、関係者も第三者も、メッセージに何らかの改竄や 変更を施していないことを確認するのに利用されます。メッセージダイジェストは、 メッセージにハッシュ関数 (指紋として知られる、秘密鍵の一部) を使うことで 得られます。ダイジェスト (署名と呼ばれます) はメッセージに添付あるいは 追加されます。署名の長さは (メッセージの長さに関らず) 一定で、 秘密鍵がもつメッセージダイジェストのタイプ (md5 は 128 ビット、 sha1 なら 160 ビット、など) によります。メッセージをたった 1 ビット変更した だけでも署名の長さは変化するので、メッセージが変更されたことが証明されます。 <sect1><!--Certificates(x509 Standard)-->証明書(x509 標準) <p> <!--Digital certificates make it possible to trust an entity on the Internet. A digital certificate contains the user's credentials, which have been verified by a neutral third-party certificate authority.--> デジタル証明書はインターネット上の存在を信頼できるようにします。 デジタル署名は、中立の第三者である証明書発行機関によって立証された、 ユーザの保証書を含みます。 <p> <!--A mathematical algorithm and a value (key) are used to encrypt data into an unreadable form. A second <em>key</em> is used to decrypt the data, using a complementary algorithm and a related value. The two keys must contain a related value and are known as a <em>key pair</em>.--> 数学的なアルゴリズムと値 (鍵) がデータを読めない形に暗号化するために使われます。 データの復号には 2 つめの<em>鍵</em>が用いられ、 これは相補的なアルゴリズムと値を使います。 2 つの鍵は関連づけられた値を持っていなければならず、 <em>鍵のペア</em> と呼ばれます。 <p> <!--Note: ITU-T Recommendation X.509 [CCI88c] specifies the authentication service for X.500 directories, as well as the X.509 certificate syntax. The certificate is signed by the issuer to authenticate the binding between the subject (user's) name and the user's public key. SSLv3 was adopted in 1994. The major difference between versions 2 and 3 is the addition of the extensions field. This field grants more flexibility as it can convey additional information beyond just the key and name binding. Standard extensions include subject and issuer attributes, certification policy information, and key usage restrictions.--> 注：ITU-T の勧告 X.509 [CCI88c] は X.509 証明書の記法のみならず、 X.500 ディレクトリへの認証サービスの仕様を定めています。 証明書は、対象の(ユーザの)名前とユーザの公開鍵とのつながりを認証するために、 発行者によって署名されます。SSLv3 は 1994 年に採択されました。 バージョン 2 と 3 の主な違いは、拡張フィールドが追加されたことです。 このフィールドにより、単なる鍵と名前のつながりだけでなく、追加の情報を 伝達することができるようになり、より柔軟になります。標準的な拡張では、 対象と発行者の帰属、認証ポリシー情報、鍵の利用制限などが含まれます。 <p> <!--An X.509 certificate consists of the following fields:--> X.509 証明書は、これらのフィールドで構成されます − <itemize> <item><!--Version-->バージョン <item><!--serial number-->シリアル番号 <item><!--signature algorithm ID-->署名アルゴリズム ID <item><!--issuer name-->発行者名 <item><!--validity period-->有効期限 <item><!--subject (user) name-->対象の(ユーザの)名前 <item><!--subject public key information-->対象の公開鍵情報 <item><!--issuer unique identifier (version 2 and 3 only)-->発行者固有の識別子(バージョン 2 と 3 のみ) <item><!--subject unique identifier (version 2 and 3 only)-->対象固有の識別子(バージョン 2 と 3 のみ) <item><!--extensions (version 3 only)-->拡張(バージョン 3 のみ) <item><!--signature on the above fields-->上記フィールドについての署名 </itemize> <sect1><!--Digital Certificate Private Key-->デジタル証明書の秘密鍵 <p> <!--The private key is not embedded within a digital certificate. The private key does not include any server information. It contains encryption information and a fingerprint. It is generated locally on your system and should remain in a secure environment. If the private key is compromised, a perpetrator essentially has the code to your security system. The transmissions between client and server can be intercepted and decrypted. This type of vulnerability is why it is recommended to create a private key that is encrypted using triple DES technology. The file is then encrypted and password protected making it all but impossible to use without the correct pass phrase.--> 秘密鍵は、デジタル証明書に埋めこまれてはいません。秘密鍵はどんなサーバ情報も もちません。秘密鍵が持つのは暗号情報と指紋です。これは自分のシステム上で ローカルに生成され、安全な環境のままでなければなりません。秘密鍵が危険に さらされれば、加害者は、本質的にそのセキュリティシステムのコードを手に したことになります。クライアントとサーバ間の送信は、傍受され、解読され得ます。 こういった弱点が、triple DES 技術を使って暗号化された秘密鍵を作ることが 推奨されている理由です。 するとファイルは暗号化され、パスワードで保護されます。これにより、 正確なパスフレーズなしに使うことがほとんど不可能になります。 <p> <!--The security of a transaction is dependent on its private key. Should this key fall into the wrong hands then anyone can easily duplicate it and use it to compromise security. A compromised key could lead to messages meant for the server to be intercepted and manipulated by unscrupulous hackers. A fully secure system must be able to detect impostors and prevent the duplication of keys.--> トランザクションのセキュリティは、その秘密鍵に依存します。この鍵が 誤った人手にわたったら、誰でも簡単にその合鍵を作って、セキュリティを 破るために使用できます。 危うい鍵は、サーバへのメッセージが無法なハッカーによって傍受され、操作される 事態を招きかねません。 完全にセキュアなシステムでは、詐称を検知でき、鍵の複製を妨害するように なっていなければなりません。 <sect1><!--Digital Certificate Public Key-->デジタル証明書の公開鍵 <p> <!--The public key is embedded in a digital certificate, which is sent by the server to a client when a secure connection is requested. This process identifies the server using the certificate. The public key validates the integrity, authenticity, and is also used to encrypt data to create a private data transmission.--> 公開鍵はデジタル証明書に埋めこまれており、セキュアな接続が要求された時に、 サーバからクライアントへ送られます。この過程により、証明書を使ってサーバの 身元が確認されます。公開鍵は完全性、信憑性を検証し、秘密のデータ転送を するためにデータを暗号化するのにも使われます。 <sect1><!--Certificate Signing Request(CSR)-->証明書署名要求(CSR) <p> <!--A CSR contains the information required by a certificate authority to create the certificate. The CSR contains an encrypted version of the private key's complimentary algorithm, common value, and information that identifies the server. This information includes, but is not limited to, country, state, organization, common name (domain name), and contact information.--> CSR は証明書発行機関が証明書を作成するのに必要となる情報を含むものです。 CSR は、秘密鍵に対して相補的なアルゴリズム、 <!--要するに「復号アルゴリズム」ですよね。--> サーバの身元を証明する情報を もちます。この情報には、国、州、組織、一般名(ドメイン名)、連絡先といった情報が 含まれますが、限定されるわけではありません。 <!--nakano すみません、とりあえずここまで--> <sect><!--Working with Certificates-->証明書による作業 <p> <!--The following section covers the steps involved in creating the private key file, certificate signing request, and a self-signed certificate. If you plan to obtain a certificate signed by a certificate authority, you will need to create a <em>certificate signing request (CSR)</em>. Otherwise, you can create a self-signed certificate.--> これ以降の節では、秘密鍵ファイルの作成、証明書署名要求、それから自署証明書を 含む手順をおさえます。証明書発行機関によって署名された証明書を入手するつもり なら、<em>証明書署名要求 (CSR)</em> を作成する必要があります。あるいは、 自署証明書を作成することもできます。 <sect1><!--Create a Private Key-->秘密鍵の作成 <p> <!--To create a private key, you must have the OpenSSL toolkit installed and configured with Apache. The following examples use the OpenSSL command line tool which is located in the /usr/local/ssl/bin directory by default. The examples assume that the directory containing the OpenSSL command line tool has been added to the $PATH.--> 秘密鍵を作るには、OpenSSL ツールキットがインストールされていて、 Apache 用に設定されている必要があります。ここからの例では、デフォルトの /usr/local/ssl/bin ディレクトリにある OpenSSL のコマンドラインツールを 使います。例では、OpenSSL のコマンドラインツールがあるディレクトリが $PATH に追加されていることを想定しています。 <p> <!--To create a private key using the triple des encryption standard (recommended), use the following command:--> トリプル DES 暗号標準 (推奨) を使って秘密鍵を作るには、このコマンドを使います − <tscreen><verb> openssl genrsa -des3 -out filename.key 1024 </verb></tscreen> <p> <!--You will be prompted to enter and re-enter a pass phrase. If you choose to use triple des encryption, you will be prompted for the password each time you start the SSL server from a cold start. (When using the restart command, you will not be prompted for the password). Some of you may find this password prompt to be a nuisance, especially if you need to boot the system during off-hours. Or, you may believe that your system is already sufficiently secure. So, if you choose not to have a password prompt (hence no triple des encryption), use the command below. If you would rather create just a 512-bit key, then omit the 1024 at the end of the command and OpenSSL will default to 512 bits. Using the smaller key is slightly faster, but it is also less secure.--> パスフレーズを入力し、また再入力するように求められます。トリプル DES を使うことにしたなら、SSL サーバをコールドスタートで起動させる度に パスワードを求められます。(再起動コマンドを使う場合は、パスワードは 聞かれません。) 特にシステムを休みの間に起動せねばならない場合、このパスワード入力が うざったいと思うかもしれません。また、システムは既に十分に堅牢だと 確信しているかもしれません。ですから、パスワード入力がないように選択する (従ってトリプル DES 暗号化を使わずに) なら、以下のコマンドを実行してください。 逆に、単に 512 bit の鍵を作りたいなら、コマンドの最後にある 1024 を 削ってください。すると OpenSSL はデフォルトの 512 bit で鍵を作ります。 小さな鍵を使うと、少しばかり早くなりますが、安全性も低下します。 <p> <!--To create a private key without triple des encryption, use the following command:--> 秘密鍵をトリプル DES 暗号化なしで作成するには、このコマンドを使います − <tscreen><verb> openssl genrsa -out filename.key 1024 </verb></tscreen> <p> <!--To add a password to an existing private key, use the following command:--> 既存の秘密鍵にパスワードを追加するには、このコマンドを使います − <tscreen><verb> openssl -in filename.key -des3 -out newfilename.key </verb></tscreen> <p> <!--To remove a password from an existing private key, use the following command:--> 既存の秘密鍵からパスワードを削除するには、このコマンドを使います − <tscreen><verb> openssl -in filename.key -out newfilename.key </verb></tscreen> <p> <bf><!--Note:-->注意：</bf><!-- Your private key will be created in the current directory unless otherwise specified. There are 3 easy ways to deal with this. If OpenSSL is in your path, you can run it from the directory that you have designated to store your key files in (default is <tt>/etc/httpd/conf/ssl.key</tt> if you installed Apache using the RPM or <tt>/usr/local/apache/conf/ssl.key</tt> if you installed Apache using the source files). Another solution is to copy the files from the directory where they were created to the correct directory. And, last but not least, you can specify the path when running the command (eg. <tt>openssl genrsa -out /etc/httpd/conf/ssl.key/filename.key 1024</tt>). Doesn't matter how you do it as long as it gets done before you proceed.--> 別途指定しなければ、秘密鍵はカレントディレクトリに作成されます。 これを取り扱うには 3 つの簡単な方法があります。OpenSSL がパスに入っていれば、 鍵ファイルを保存するために選んだディレクトリから実行することができます (Apache のインストールに RPM を使った場合のデフォルトは <tt>/etc/httpd/conf/ssl.key</tt> で、ソースファイルからインストールしたのなら <tt>/usr/local/apache/conf/ssl.key</tt> です)。 別解は、鍵が作成されたディレクトリから、正しいディレクトリへとファイルを コピーすることです。さらに、大事なことを言い忘れましたが、コマンドの実行時にパスを 指定することができます (eg. <tt>openssl genrsa -out /etc/httpd/conf/ssl.key/filename.key 1024</tt>)。 次に進む前に作業が終わっていれば、方法はどれでも構いません。 <p> <!--For more information on the OpenSSL toolkit check out: <url url="http://www.openssl.org/" name="OpenSSL Website">.--> OpenSSL ツールキットについてのより詳しい情報は、ここ見てください − <url url="http://www.openssl.org/" name="OpenSSL Website"> <sect1><!--Create a Certificate Signing Request-->証明書署名要求の作成 <p> <!--To obtain a certificate signed by a certificate authority, you will need to create a Certificate Signing Request (CSR). The purpose is to send the certificate authority enough information to create the certificate without sending the entire private key or compromising any sensitive information. The CSR also contains the information that will be included in the certificate, such as, domain name, locality information, etc.--> 証明書発行機関によって署名された証明書を入手するには、証明書署名要求 (CSR) を作成する必要があります。目的は、秘密鍵を丸ごと送ったり、 扱いの難しい情報を危険にさらしたりすることなく、証明書を作成するに足る情報を 証明書発行機関に送ることです。CSR は、例えばドメイン名や地域情報といった、 証明書に含まれる情報ももっています。 <itemize> <item> <!--Locate the private key that you would like to creat a CSR from. Enter the following command:--> CSR を作るもとの秘密鍵を確認します。このコマンドを入力してください − <tscreen><verb> openssl req -new -key filename.key -out filename.csr </verb></tscreen> </item> <item> <!--You will be prompted for Locality information, common name (domain name), organizational information, etc. Check with the CA that you are applying to for information on required fields and invalid entries.--> 地域情報、共通名 (ドメイン名)、組織情報などの入力を求められます。 必要とされる項目と、不適切なエントリの情報を、採用しようとしている CA に問い合わせてください。 </item> <item> <!--Send the CSR to the CA per their instructions.--> CSR を CA の指示に従って送ります。 </item> <item> <!--Wait for your new certificate and/or create a self-signed certificate. A self-signed certificate can be used until you receive your certificate from the certificate authority.--> 新しい証明書を待ちつつ、あるいは自署証明書を作成してください。 自署証明書は証明書発行機関から証明書を受けとるまで使用することができます。 </item> </itemize> <p> <bf><!--Note:-->注意：</bf><!-- Use the following command to create a private key and request at the same time.--> 秘密鍵と要求(訳注:CSR)を同時に作成するには、次のコマンドを使います。 <tscreen><verb> openssl genrsa -des3 -out filename.key 1024 </verb></tscreen> <sect1><!--Creating a Self-Signed Certificate-->自署証明書の作成 <p> <!--It is not necessary to create a self-signed certificate if you are obtaining a CA-signed certificate. However, creating a self-signed certificate is very simple. All you need is a private key and the name of the server (fully qualified domain name) that you want to secure. You will be prompted for information such as locality information, common name (domain name), organizational information, etc. OpenSSL gives you a great deal of freedom here. The only required field for the certificate to function correctly is the common name (domain name) field. If this is not present or incorrect, you will receive a <em>Certificate Name Check</em> warning from your browser.--> CA の署名した証明書を入手しようとしているなら、自署証明書を作る必要はありません。とはいえ、自署証明書の作成はたいへん簡単です。必要なのは、秘密鍵とセキュアにしたいサーバの名前 (完全修飾ドメイン名) です。地域情報や共通名 (ドメイン名)、組織情報などを訊ねられます。OpenSSL では、ここでかなりの自由がききます。証明書が正常に機能するために唯一必要な情報は、共通名 (ドメイン名) です。これがなかったり、欠けたりしていると、<em>Certificate Name Check</em> 警告をブラウザから受けることになります。 <p><!--To create a self-signed certificate:-->自署証明書を作成するには − <tscreen><verb> openssl req -new -key filename.key -x509 -out filename.crt </verb></tscreen> <sect1><!--Installing your Web Server Certificate-->ウェブサーバへの証明書のインストール <p> <!--If you followed these instructions so far you shouldn't have any problems at this point. If you sent your CSR to a certificate authority and you have not gotten your certificate back yet, you can take a break now! If you are using a self-signed certificate, or you have received your certificate, you may continue.--> これらの指示に従っていたら、今までのところ、ここまででは特に問題は起きていないはずです。CSR を証明書発行機関に送って、まだ証明書を受けとっていないなら、ちょっと一休みしましょう！　自署証明書を使っているか、証明書を受けとりずみなら、次に進んでも構いません。 <itemize> <item> <!--Ensure that the private key file is in the directory that you have chosen to use. The following examples will be based on the RedHat RPM installation default of <tt>/etc/httpd/conf/ssl.key</tt>.--> 秘密鍵ファイルが、使うと決めた場所にあることを確認してください。続く例は RedHat RPM によるインストールのデフォルト値、<tt>/etc/httpd/conf/ssl.key</tt> に基いています。 </item> <item> <!--Ensure that the CA-signed or self-signed certificate is in its designated location. Again, I will be using the RPM default of <tt>/etc/httpd/conf/ssl.crt</tt>. If it is not there already, put it there.--> CA が署名した、あるいは自署の証明書が指定されたディレクトリにあることを確認してください。繰り返しますが、私は RPM のデフォルトである <tt>/etc/httpd/conf/ssl.crt</tt> を使います。まだそこになければ、そこに配置してください。 </item> <item> <!--If there is an intermediate (root) certificate to be installed, copy it to the <tt>/etc/httpd/conf/ssl.crt</tt> directory, also.--> もし、インストールする中間証明書 (またはルート証明書) があるなら、それも <tt>/etc/httpd/conf/ssl.crt</tt> ディレクトリにコピーしてください。 </item> <!--nakano http://support.microsoft.com/intl/japan/support/productflashes/Internet/intfc406_j.htm あたりだと訳されてないので、 「中間証明書 (intermidiate certificate) あるいはルート証明書 (root certificate)」 とかにしとくのはどうでしょうか。 --> <item> <!--Now, you will be required to edit the httpd.conf file. Make a back-up of this file before you proceed to the next step, <ref id="configure" name="Configuring your Apache Server">.--> 次は、httpd.conf ファイルを編集する必要があります。次のステップ、<ref id="configure" name="Apache Server の設定"> に進む前に、このファイルのバックアップを作ってください。 </item> </itemize> <sect><!--Configuring your Apache Server-->Apache Server の設定 <label id="configure"> <p> <!--The Apache server must be configured with supplementary API modules in order to support SSL. There are many SSL software packages available. My examples are based on Apache configured with ModSSL and OpenSSL. There are countless mailing lists and newsgroups available to support these products. You may find these instructions helpful for some commercial SSL software packages that are based on the Apache web server.--> SSL をサポートするためには、Apache は追加の API モジュールを使うように設定される必要があります。多くの SSL ソフトウェアパッケージが利用できます。私の例では、ModSSL と OpenSSL 用に設定された Apache を元にしています。これらのプロダクトをサポートする数え切れないくらいのメーリングリストやニュースグループがあります。 Apache ウェブサーバを元にしているいくつかの商用 SSL パッケージにも、これらの手引きが有用だと思うかもしれません。 <p> <!--A few things to keep in mind: You can have multiple virtual hosts on the same server. You can have numerous name-based virtual hosts on the same IP address. You can also have numerous name-based virtual hosts and one (1) secure virtual host on the same IP. But - you cannot have multiple secure virtual hosts on the same IP. The question that so many ask: Why? The answer is: SSL works below the application layer. Name based hosts are not defined until the application layer.--> いくつか頭に入れておくべきことがあります − 同じサーバに複数のヴァーチャルホストをたてることができます。同じ IP アドレスで、名前ベースのヴァーチャルホストを多数たてることができます。同じ IP アドレスで、名前ベースのヴァーチャルホストを多数と、セキュアなヴァーチャルホストを 1 つたてることもできます。ただし − 同じ IP アドレスで、複数のセキュアなヴァーチャルホストをたてることはできません。多くの人がこう訊ねるでしょう − 何故？　と。答えはこうです − SSL はアプリケーション層の下で機能します。名前ベースのホストは、アプリケーション層までは定義されていません。 <p> <!--Specifically, you cannot have multiple secure virtual hosts on the same SOCKET (IP address + port). By default, a secure host will use port 443. You can change configure your virtual host to use a different port number with the same IP, thus creating another socket. There are many disadvantages to this approach. The most obvious disadvantage is that if you are not using the default port, your URL must also contain the port number to access the secure site.--> 特に、同じ SOCKET (IP アドレス + ポート) について、複数のセキュアなヴァーチャルホストをたてることはできません。デフォルトでは、セキュアなホストはポート 443 を使います。ヴァーチャルホストが同じ IP アドレスで異なるポート番号を使うことで、別のソケットを作成するように設定を変更することはできます。この方法には数多くの不都合があります。一番明確な不都合は、デフォルトポートを使っていない場合、セキュアサイトへのアクセスにおいて、URL にポート番号を含めなくてはならないことです。 <p> <!--Example:--> 例えば： <itemize> <item><!--Site using default port - www.something.com - would be accessed as <tt>https://www.something.com</tt>-->デフォルトポートを使うサイト、www.something.com は、<tt>https://www.something.com</tt> でアクセスできます <item><!--A site using port 8888 would be accessed as <tt>https://www.something.com:8888</tt>-->ポート 8888 を使うサイトでは、<tt>https://www.something.com:8888</tt> でアクセスできます。 </itemize> <p> <!--Another disadvantage is that if you introduce more ports, you will be providing more opportunities for port sniffing hackers. Last, if you select a port that is used by something else, you will create conflict problem.--> もう一つの不都合は、たくさんのポートを使うと、ポートを嗅ぎまわるハッカーにより機会を与えることになる、ということです。最後に、選んだポートが何か他で使われていると、衝突問題が発生することになります。 <sect1><!--Define a Secure Virtual Host-->セキュアなヴァーチャルホストの定義 <P> <!--Setting up virtual hosts is fairly straightforward. I will go through the basics of setting up a secure virtual host.--> ヴァーチャルホストの設置は、全く簡単です。セキュアなヴァーチャルホストを設定する基本を、検討していきます。 <p> <!--In these examples, I use the <tt>.crt</tt> and <tt>.key</tt> file extensions. That is my personal way of avoiding confusion with the various files. With Apache, you can use any extension you choose - or no extension at all.--> これらの例において、<tt>.crt</tt> と <tt>.key</tt> ファイル拡張子を使います。 これは、様々なファイルとの混乱を避ける、個人的な方法です。Apache を使うなら、 好きな拡張子を使えますし、あるいは拡張子なしにもできます。 <p> <!--All of your secure virtual hosts should be contained within <tt><IfDefine SSL></tt> and <tt></IfDefine SSL></tt>, usually located towards the end of the httpd.conf file.--> セキュアなヴァーチャルホストは全て、通常は httpd.conf ファイルの末尾に配置 される、<tt><IfDefine SSL></tt> と <tt></IfDefine SSL></tt> に包含される必要があります。 <p> <!--An example of a secure virtual host:--> セキュアなヴァーチャルホストの例です − <tscreen><verb> <VirtualHost 172.18.116.42:443> DocumentRoot /etc/httpd/htdocs ServerName www.somewhere.com ServerAdmin someone@somewhere.com ErrorLog /etc/httpd/logs/error_log TransferLog /etc/httpd/logs/access_log SSLEngine on SSLCertificateFile /etc/httpd/conf/ssl.crt/server.crt SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server.key SSLCACertificateFile /etc/httpd/conf/ssl.crt/ca-bundle.crt <Files ~ "\.(cgi|shtml)$"> SSLOptions +StdEnvVars </Files> <Directory "/etc/httpd/cgi-bin"> SSLOptions +StdEnvVars </Directory> SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown CustomLog /etc/httpd/logs/ssl_request_log \ "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b" </VirtualHost> </verb></tscreen> <p> <!--The directives that are the most important for SSL are the <tt>SSLEngine on</tt>, <tt>SSLCertificateFile</tt>, <tt>SSLCertificateKeyFile</tt>, and in many cases <tt>SSLCACertificateFile</tt> directives.--> SSL について最も重要なディレクティブは、<tt>SSLEngine on</tt>, <tt>SSLCertificateFile</tt>, <tt>SSLCertificateKeyFile</tt>, それから多くの場合で <tt>SSLCACertificateFile</tt> です。 <sect2>SSL Engine <p> "<tt>SSLEngine on</tt>"<!-- - this is ModSSL's command to start SSL.-->− これは、SSL を開始するための ModSSL コマンドです。 <sect2>SSLCertificateFile <p> <!--<tt>SSLCertificateFile</tt> Tells Apache where to find the certificate file and what it is named. The example above shows "server.crt" as the certificate file name. This is the default that is added when you configure ModSSL with Apache. I personally don't recommend using the default names. Save yourself some frustration and name your certificates as servername.crt (domainname.crt). You may also decide to use an alternative directory than the default <tt>/etc/httpd/conf/ssl.crt</tt> or <tt>/usr/local/apache/conf/ssl.crt</tt>. Just remember to make the necessary changes to the path.--> <tt>SSLCertificateFile</tt> は、Apache に証明書ファイルの在処と、 それがなんという名前なのかを指示します。上の例では、"server.crt" が証明書ファイル名として示されています。これは、Apache と一緒に ModSSL を設定した時に追加されるデフォルトです。個人的には、デフォルトの名前を 使うことはお勧めしません。面倒なのをこらえて、証明書にサーバ名.crt (ドメイン名.crt) と名付けてください。同じように、デフォルトの <tt>/etc/httpd/conf/ssl.crt</tt> や <tt>/usr/local/apache/conf/ssl.crt</tt> とは別のディレクトリを使うこともできます。 <sect2>SSLCertificateKeyFile <p> <!--<tt>SSLCertificateKeyFile</tt> tells Apache the name of the private key and where to find it. The directory defined here should have read/write permissions for root only. No one else should have access to this directory.--> <tt>SSLCertificateKeyFile</tt> は、Apache に秘密鍵の名前とその在処を指示します。ここで指定されたディレクトリは root のみが読み/書き権限を持っている必要があります。他には誰もこのディレクトリにアクセスするべきではありません。 <sect2>SSLCACertificateFile <p> <!--The <tt>SSLCACertificateFile</tt> directive tells Apache where to find the Intermediate (root) certificate. This directive may or may not be necessary depending on the CA that you are using. This certificate is essentially a ring of trust.--> <tt>SSLCACertificateFile</tt> ディレクティブは、Apache に中間証明書の場所を指示します。このディレクティブは、使用している CA によって必要だったり不必要だったりします。この証明書が本質的に信頼の輪となります。 <p> <!--<bf>Intermediate Certificate</bf> - A Certificate Authority obtains a certificate in much the same way as you. This is known as an intermediate certificate. It basically says that the holder of the intermediate certificate is whom they say they are and is authorized to issue certificates to customers. Web browsers have a list of "trusted" certificate authorities that is updated with each release. If a Certificate authority is fairly new, its intermediate certificate may not be in the browser's list of trusted CA's. Combine this with the fact that most people don't update their browsers very often; it could take years before a CA is recognized as trusted automatically. The solution is to install the intermediate certificate on the server using the <tt>SSLCACertificateFile</tt> directive. Usually, a "trusted" CA issues the intermediate certificate. If it is not, then you may need to use the <tt>SSLCertificateChainFile</tt> directive, although this is unlikely.--> <bf>中間証明書</bf> − 証明書発行機関は、あなたとほとんど同じ方法で証明書を得ます。これは、中間証明書として知られています。これは、基本的には中間証明書の所持者が、 いうものです。 ウェブブラウザは、各リリースごとに更新される、"信頼できる" 証明発行機関のリストを持っています。証明書発行機関が全く新しいなら、その中間証明書は、ブラウザの信頼できる CA リストには入っていないでしょう。ほとんどの人が自分のブラウザをそう頻繁にアップデートしたりしないという事実をこれと合わせると、こうなります − CA が自動的に信頼できるものとして認識されるには、数年かかります。解決策は、 <tt>SSLCACertificateFile</tt> ディレクティブを使って、サーバに中間証明書をインストールすることです。たいてい、"信頼された" CA は中間証明書を発行しています。もしそうでなければ、<tt>SSLCertificateChainFile</tt> ディレクティブを使わねばならないかも知れませんが、これはまずないことです。 <sect1><!--Certificate Examples-->証明書の例 <sect2><!--Server Certificate File-->サーバ証明書ファイル <p> <tscreen><verb> -----BEGIN CERTIFICATE----- MIIC8DCCAlmgAwIBAgIBEDANBgkqhkiG9w0BAQQFADCBxDELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMR0wGwYD VQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UECxMfQ2VydGlmaWNhdGlv biBTZXJ2aWNlcyBEaXZpc2lvbjEZMBcGA1UEAxMQVGhhd3RlIFNlcnZlciBDQTEm MCQGCSqGSIb3DQEJARYXc2VydmVyLWNlcnRzQHRoYXd0ZS5jb20wHhcNOTkwNTI1 MDMwMDAwWhcNMDIwNjEwMDMwMDAwWjBTMQswCQYDVQQGEwJVUzEbMBkGA1UEChMS RXF1aWZheCBTZWN1cmUgSW5jMScwJQYDVQQDEx5FcXVpZmF4IFNlY3VyZSBFLUJ1 c2luZXNzIENBLTIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMYna8GjS9mG q4Cb8L0VwDBMZ+ztPI05urQb8F0t1Dp4I3gOFUs2WZJJv9Y1zCFwQbQbfJuBuXmZ QKIZJOw3jwPbfcvoTyqQhM0Yyb1YzgM2ghuv8Zz/+LYrjBo2yrmf86zvMhDVOD7z dhDzyTxCh5F6+K6Mcmmar+ncFMmIum2bAgMBAAGjYjBgMBIGA1UdEwEB/wQIMAYB Af8CAQAwSgYDVR0lBEMwQQYIKwYBBQUHAwEGCCsGAQUFBwMDBgorBgEEAYI3CgMD BglghkgBhvhCBAEGCCsGAQUFBwMIBgorBgEEAYI3CgMCMA0GCSqGSIb3DQEBBAUA A4GBALIfbC0RQ9g4Zxf/Y8IA2jWm8Tt+jvFWPt5wT3n5k0orRAvbmTROVPHGSLw7 oMNeapH1eRG5yn+erwqYazcoFXJ6AsIC5WUjAnClsSrHBCAnEn6rDU080F38xIQ3 j1FBvwMOxAq/JR5eZZcBHlSpJad88Twfd7E+0fQcqgk+nnjH -----END CERTIFICATE----- </verb></tscreen> <sect2><!--Contents of the Certificate File-->証明書ファイルの内容 <p> <tscreen><verb> Certificate: Data: Version: 3 (0x2) Serial Number: 1516 (0x5ec) Signature Algorithm: md5WithRSAEncryption Issuer: C=US, O=Equifax Secure Inc, CN=Equifax Secure E-Business CA Validity Not Before: Jul 12 15:21:01 2000 GMT Not After : Jun 2 22:42:34 2001 GMT Subject: C=us, ST=ga, L=atlanta, O=Equifax, OU=Rick, CN=172.18.116.44/Email=richard.sigle@equifax.com Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:c8:eb:93:26:97:ca:00:ce:4c:e4:f3:fd:43:31: cd:53:ed:b4:8a:ad:93:84:dc:7a:48:39:b5:28:57: 03:7f:a9:ac:3e:58:6a:7a:e3:52:3e:1e:52:58:a2: 6f:23:ad:bb:84:d8:88:ed:6d:a5:da:08:6b:c8:6c: a5:4c:34:67:d8:46:1c:ca:20:50:b0:e8:54:7f:ca: 5e:ef:09:ff:6e:8d:a6:2b:02:f5:54:0f:c2:d0:45: 12:ad:66:e7:8b:dd:68:be:64:a4:9b:69:bd:a4:1a: 5e:ef:09:ff:6e:8d:a6:2b:02:f5:54:0f:c2:d0:45: 12:ad:66:e7:8b:dd:68:be:64:a4:9b:69:bd:a4:1a: 5a:2f:3b:6e:73:84:d8:d6:17:bd:12:39:34:fa:3d: d8:a9:e8:59:3c:c2:61:c5:b3 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment Netscape Cert Type: SSL Server X509v3 Authority Key Identifier: keyid:5B:E0:A8:75:1C:78:02:47:71:AB:CE:27:32:E7:24:88:42:28:48:56 Signature Algorithm: md5WithRSAEncryption 87:53:74:e9:e1:a6:10:56:8c:fa:63:0e:7b:72:ff:76:4b:79: 0e:49:2a:58:ed:71:7a:bf:77:61:fa:e8:74:04:37:8c:d3:6a: 9a:3d:80:76:7a:c3:64:30:e7:1b:40:25:4e:2a:81:8b:e5:ac: 76:a4:38:67:cc:3f:93:43:e1:1d:c3:8d:ba:ed:cc:d7:aa:a4: ab:d3:84:77:7c:8f:26:f6:dd:ba:3b:6a:99:81:e1:9e:7e:0f: ca:a6:ff:c0:c3:59:6e:dc:a6:03:23:bf:8f:24:ff:15:ad:ac: 0d:85:fc:38:bf:d1:24:2d:1a:d3:72:55:12:95:5f:65:f0:60: df:b1 </verb></tscreen> <sect2><!--Private Key File-->秘密鍵ファイル <p> <tscreen><verb> -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,124F61450D85A480 ELz64SV+tFSRybsHjY9NH7CP7yDHXP6xcd9FY6MVgQykTkq2h0n7j+tmpfUPbStT 6jCgm/dTYM9mpkQ3jYZBALiVD5JNJ9t1dWisxQXY/nsak8LSTN7LhUtZSfk5xSmV Zsl4gwQS20UdBzFiJ+4qDajP/pzocSdSuQvxIHq7UzNwJsW8UYxR3I1qrDgyNXKS db41BWH4QdNtE0p+pi9VndDzXktqZGHEvtrQTV+39DV/dwOdnGBpYBETljMO5X6t D42xcVs0Doa1vZ6PiMCkwFNPXsPlKHZtHwEL4I3CQdiH4E0oYh3klBzlXBY4YldN A+s4xU44FpXp5xwt9nnVPUKHPo+NpdaRK7dAcRNO3GN3+ek1ggzvEjjuWKes3RQh PlHPuF7VWo4KeaTfTIwJWfGxz4nvwlVByPJ6Z73Mn0VcDXCkVm6+h3PLlYL0FMqM baUyQPpw6bhfW71FO/IIQxz3R1EqkxW7OHv74uuYl8kjHXf3S6qRZEGUG/zOGLGr mI5s2qnU69HlBObFkc6WQq0QxMq4PiUi7HhCLMkH8+wBsNNMnb75+7lQKkEhdOeE iUMKe5kgQqfd9w8jsBH5nu+J/nCfvPdp0isQW+P3/Rrh6YMwdKnlVfNZWdGiTzpQ ngThAGq5lit4uf4zdTIYYrs+T9I5ltjj0KgCUD4VL5/7OfnR3gcphpbHXQf0E2cz Qwq7q7ppKwCf/x92pHi8oVevlV5Dx9NQbGhEOA5pooqD6S2xZBbPLzkUKWDEO2il oBZ5L1jClR5jjdF2U61w7aRrL0t6luDU/aRv/fcoYes= -----END RSA PRIVATE KEY----- </verb></tscreen> <sect2><!--Contents of the Private Key-->秘密鍵ファイルの内容 <p> <tscreen><verb> read RSA key Enter PEM pass phrase: Private-Key: (1024 bit) modulus: 00:c8:eb:93:26:97:ca:00:ce:4c:e4:f3:fd:43:31: cd:53:ed:b4:8a:ad:93:84:dc:7a:48:39:b5:28:57: 03:7f:a9:ac:3e:58:6a:7a:e3:52:3e:1e:52:58:a2: 6f:23:ad:bb:84:d8:88:ed:6d:a5:da:08:6b:c8:6c: a5:4c:34:67:d8:46:1c:ca:20:50:b0:e8:54:7f:ca: 5e:ef:09:ff:6e:8d:a6:2b:02:f5:54:0f:c2:d0:45: 12:ad:66:e7:8b:dd:68:be:64:a4:9b:69:bd:a4:1a: 5a:2f:3b:6e:73:84:d8:d6:17:bd:12:39:34:fa:3d: d8:a9:e8:59:3c:c2:61:c5:b3 publicExponent: 65537 (0x10001) privateExponent: 00:b6:57:7d:3b:58:24:1e:a9:1b:85:e9:9c:9e:5f: d3:3d:69:0c:21:93:37:bf:2b:2c:da:e1:6c:74:48: cb:c7:0f:60:5f:50:74:8a:44:45:be:54:5c:5d:4e: 45:58:f6:f1:a8:b5:af:46:f2:ec:c2:bc:43:bd:28: 44:b7:ad:13:d3:ca:de:59:24:e8:fa:f8:e5:5f:45: 38:2c:a0:a3:de:98:13:d8:80:38:e1:47:53:4c:ea: e4:66:c3:82:93:89:c3:90:83:44:e1:13:4f:74:76: e2:c0:89:97:77:5f:33:d8:7d:27:21:52:55:c2:d7: dc:01:f9:bc:21:8d:a3:f5:c1 prime1: 00:e3:2d:6b:5e:05:6b:e1:46:e6:ab:ae:f3:8b:d0: 5f:94:5c:6f:f5:47:46:1d:4e:66:d3:7e:98:18:e0: 2c:0d:08:ca:b7:29:72:af:53:62:30:ec:be:26:1f: cc:5a:ed:65:62:65:70:1e:18:19:61:e3:77:00:a7: 3a:9e:4e:12:93 prime2: 00:e2:69:56:78:e8:39:ff:17:db:cc:39:d7:7f:70: 41:dc:c5:59:43:16:c1:84:4c:ae:e7:5d:8a:c5:4b: da:88:8e:03:99:7c:88:f2:8a:13:31:57:44:e0:b5: c8:0a:60:b0:05:de:f6:9e:f2:00:ec:37:21:8d:3b: dc:8e:c9:d4:61 exponent1: 1a:ad:6a:be:4f:c4:ab:5f:b8:16:d1:24:a8:76:7f: c2:dc:58:09:65:a5:46:2b:be:c7:77:46:45:25:8e: 06:b9:d1:94:50:b9:b6:fd:03:ba:db:12:39:47:e2: a7:8a:d9:2d:04:dc:75:ac:3e:ce:cf:f7:59:8c:49: c5:ed:45:21 exponent2: 2d:4e:fd:32:06:ef:0c:40:7f:08:d8:8e:6a:7f:51: 7e:d7:b3:6c:3c:92:8f:62:35:22:31:d3:02:76:92: 8d:ff:35:73:32:bb:c9:25:9e:7f:a2:42:33:61:cd: 5d:5e:49:fb:72:ca:11:b6:c6:3e:7f:2d:e4:b0:95: 0b:b2:12:21 coefficient: 50:52:09:22:cb:fb:b2:b8:58:85:ab:1d:82:b9:6e: d0:f6:dc:e8:ce:a6:5d:a1:ff:c8:4d:3b:2b:1c:19: 64:f0:c4:4a:bc:b2:1d:2b:2d:09:59:83:a3:9a:89: f8:db:2c:2c:8a:bd:fd:a3:16:51:76:aa:ce:ea:85: 6b:1c:9f:f7 </verb></tscreen> <sect1><!--Restart the Web Server-->Web サーバの再起動 <p> <!--The script to restart the webserver may be located in <tt>/usr/local/sbin</tt>, <tt>/usr/sbin</tt>, (where the script is called <tt>httpd</tt>) or <tt>/usr/local/apache/bin</tt> (where the script is called <tt>apachectl</tt>). If you are not running the server with SSL enabled, you will need to stop and start the server. You may also write your own customized scripts to start, restart, and stop your server. As long as it starts the SSL engine, you should be OK.--> ウェブサーバを再起動するスクリプトは、おそらく <tt>/usr/local/sbin</tt>か、<tt>/usr/sbin</tt> (<tt>httpd</tt> というスクリプト名で)、あるいは <tt>/usr/local/apache/bin</tt> (<tt>apachectl</tt> というスクリプト名で) にあるでしょう。 SSL を有効にしてサーバを起動していないなら、サーバを停止して、 起動させる必要があります。開始、再起動、停止のために、自分用のカスタマイズしたスクリプトを書いても構いません。SSL エンジンが起動する限り、問題はありません。 <p> <!--The commands are:-->コマンドは − <tscreen><verb> httpd stop httpd startssl httpd restart </verb></tscreen> <!--<em>or</em>--><em>あるいは</em> <tscreen><verb> apachectl stop apachectl startssl apachectl restart </verb></tscreen> <sect><!--Troubleshooting-->トラブルシューティング <p> <!--Here are some common problems that may arise.--> 発生しうる、ありがちな問題をいくつか書いておきます。 <sect1><!--Server Appears to start, but you cannot access the secure site-->サーバは起動したように見えるが、セキュアサイトにアクセスできない <p> <!--Check the <tt>error_log</tt> file. If you did not set your virtual host to write to an error log, you may want to reconsider. The example SSL virtual host writes to an error log file. Most likely you will have a few warnings and an error at the end of the log that basically say that the private key does not match the certificate.--> <tt>error_log</tt> ファイルをチェックしてください。ヴァーチャルホストが エラーログを書くように設定していないなら、考え直した方がいいかも知れません。 例示した SSL ヴァーチャルホストは、エラーログファイルに出力します。 多分、2, 3 の警告と、ログの最後にエラーがあり、基本的には秘密鍵が証明書と 一致しない、という内容でしょう。 <p> <!--Example:-->例： <tscreen><verb> [Tue Nov 21 09:09:02 2000] [notice] Apache/1.3.14 (Unix) mod_ssl/2.7.1 OpenSSL/0.9.6 configured -- resuming normal operations [Tue Nov 21 09:09:16 2000] [notice] caught SIGTERM, shutting down [Tue Nov 21 14:39:54 2000] [notice] Apache/1.3.14 (Unix) mod_ssl/2.7.1 OpenSSL/0.9.6 configured -- resuming normal operations [Tue Nov 21 14:40:31 2000] [notice] caught SIGTERM, shutting down [Tue Nov 21 14:43:53 2000] [error] mod_ssl: Init: (esi.fin.equifax.com:443) Unable to configure RSA server private key (OpenSSL library error follows) [Tue Nov 21 14:43:53 2000] [error] OpenSSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch </verb></tscreen> <p> <!--If you get the error messages above, chances are the key and certificate do not match. Make sure you aren't using the default <tt>server.key</tt> file. You should also check the <tt>httpd.conf</tt> file to make sure that the directives are pointing to the correct private key and certificate.--> 上記のエラーメッセージを得たなら、問題は鍵と証明書が一致しないことです。 デフォルトの <tt>server.key</tt>ファイルを使っていないことを確認してください。 また、<tt>httpd.conf</tt> ファイルをチェックして、ディレクティブが正しい秘密鍵と証明書を指しているかの確認もするべきです。 <p> <!--You can check to make sure that you your private key and certificate are in the correct format and match each other. To do this, give the commands below to decrypt the private key in one terminal window and decrypt the certificate in the other. What you will be comparing are the Modulus and the Exponent of each key. If the modulus and exponent from the key matches the set from the certificate, you have just confirmed that your certificate and key are correctly paired.--> 確認のため、秘密鍵と証明書の書式が正確で、お互いに対をなしていることを調べることもできます。このためには、下のコマンドを使って秘密鍵をターミナルウィンドウに復号化し、別のウィンドウで証明書を復号化してください。 比較するのは、鍵それぞれのモジュールと実体です。鍵のモジュールと実体が証明書のそれと一致するならば、その証明書と鍵が正しく対になっているといえます。 <p> If all else fails, create a new private key, CSR or self-signed certificate. Before you do this, check your CA's re-issue policy. You may be charged for a re-issue. <p> To view the contents of the certificate: <tscreen><verb> openssl x509 -noout -text -in filename.crt </verb></tscreen> <p> To view the contents of the private key: <tscreen><verb> openssl rsa -noout -text -in filename.key </verb></tscreen> <sect1>Certificate Name Check Warning is issued by the client's browser <p> The most common cause for this is omitting the "www" at the beginning of the domain name when creating the CSR. The name defined by the "ServerName" directive for that virtual host must match the domain name presented by the certificate exactly or the browser will let the client know. The exception is a wild card certificate. A wild card certificate's domain name field would look like *.somedomain.com. This enables you to use one certificate for any number of sub-domains of somedomain.com (e.g. host1.somedomain.com and host2.somedomain.com). <sect1><!--Certificate was Signed by an Untrusted Certificate Authority Warning is issued by the client's browser--> クライアントのブラウザに、証明書が信頼されていない証明書発行機関 <p> If you are using a self-signed certificate, you will get this warning. Your clients will be given the option to trust your certificate or not. If you have a CA signed certificate and are getting the untrusted warning, you probably need to install their intermediate (root) certificate. <sect1>SSLEngine on is an un-recognized command <!--(when starting Apache)-->(Apache の起動時) <p> <!--This error message is issued if you do not have ModSSL compiled with Apache. Some SSL packages use a different directive to start SSL within a virtual host. If you are using a package that does use a different directive, you will also receive this error message.--> このエラーメッセージは、Apache と一緒に ModSSL をコンパイルしなかった場合に 発生します。ヴァーチャルホストで SSL を使うのに、別のディレクティブを使う SSL パッケージもあります。別のディレクティブを使うパッケージを使っている場合 このエラーメッセージをまた見ることになります。 <sect1><!--You have forgotten your "PEM Passphrase" and you would like to know how to reset it--> "PEM パスフレーズ" を忘れてしまい、どうやってそれを再設定するか知りたい。 <p> <!--There is no way to reset this passphrase. The only solution is to remember the passphrase or create a new private key. You will then need to obtain a new certificate or create a new self-signed certificate.--> このパスフレーズを再設定する方法はありません。解決するには、パスフレーズを憶えて おくか、新しい秘密鍵を作成するしかありません。そうすると、新しい証明書を取得 するか、新しい自署証明書を作成する必要がでてくるでしょう。 <sect><!--Glossary-->用語集 <p> <descrip> <!--<tag/Authentication/ The positive identification of a network entity such as a server, a client, or a user. In SSL context, authentication represents the server and client Certificate verification process.--> <tag/認証/サーバやクライアント、ユーザといったネットワーク上の存在を、 明確に同一であると証明すること。SSL の文脈では、認証はサーバとクライアント における証明書の照合過程をいいます。 <!--<tag/Access Control/ The restriction of access to network realms. In Apache context usually the restriction of access to certain URLs.--> <tag/アクセス制御/ネットワーク領域へのアクセスを制限すること。 通常 Apache の文脈では、ある URL へのアクセスを制限すること。 <!--<tag/Algorithm/ An unambiguous formula or set of rules for solving a problem in a finite number of steps. Algorithms for encryption are usually called Ciphers.--> <tag/アルゴリズム/限られた手数で問題を解決するための明白な定式、 あるいは規則の組。暗号化のためのアルゴリズムは、通常 cipher と呼ばれます。(訳注：本文では、cipher も暗号、などと訳してます。) <!--<tag/Certificate/ A data record used for authenticating network entities such as a server or a client. A certificate contains X.509 information pieces about its owner (called the subject) and the signing Certificate Authority (called the issuer), plus the owner's public key and the signature made by the CA. Network entities verify these signatures using CA certificates.--> <tag/証明書/サーバやクライアントといったネットワークエンティティを 認証するのに使われる、データレコード。証明書は、その所有者 (subject と呼ばれます) と署名をする証明書発行機関 (issuer と呼ばれます) に関する X.509 の情報断片、加えて所有者の秘密鍵と CA によって作成された 署名を含みます。ネットワークエンティティはこれらの署名を検証するのに、 CA の証明書を使います。 <!--<tag/Certificate Authority (CA)/ A trusted third party whose purpose is to sign certificates for network entities that it has authenticated using secure means. Other network entities can check the signature to verify that a CA has authenticated the bearer of a certificate.--> <tag/認証機関 (CA)/信頼されている第三者機関で、ネットワークエンティティが 安全な手段で認証されるために、その証明書に署名するのが目的です。 他のネットワークエンティティは署名をチェックして、 CA が証明書の運び手として認証されていることを確認することができます。 <!--<tag/Certificate Signing Request (CSR)/ An unsigned certificate for submission to a Certification Authority, which signs it with the Private Key of their CA Certificate. Once the CSR is signed, it becomes a real certificate. Cipher An algorithm or system for data encryption. Examples are DES, IDEA, RC4, etc.--> <tag/証明書署名要求 (CSR)/認証機関に提出される署名されていない証明書で、 その CA 証明書の秘密鍵で署名されます。CSR は署名されることで真の証明書となります。 <tag/サイファ/ データの暗号化のために使うアルゴリズムやシステム。例えば、DES, IDEA, RC4 などです。(訳注：原文のミスと想定して訳に手を加えています) <!--nakano これは原文のミスのような気が--> <!--<tag/Ciphertext/ The result after a Plaintext passed a Cipher.--> <tag/暗号文/プレインテキストに暗号法を施した結果。 <!--<tag/Configuration Directive/ A configuration command that controls one or more aspects of a program's behavior. In Apache context these are all the command names in the first column of the configuration files.--> <tag/設定ディレクティブ/プログラムの挙動において、1 つ以上の側面を 操作する設定命令。Apache の文脈では、設定ファイルの最初のカラムに あらゆる命令がきます。 <!--<tag/Cryptography - Symmetric/ The client and server use the same key to encrypt and to decrypt data.--> <tag/暗号化 − 対称/クライアントとサーバが、データの暗号化と復号化に同じ鍵を用います。 <!--<tag/Cryptography - Asymmetric/ Consists of a key pair (public and private). PKI is Asymmetric Cryptography--> <tag/暗号化 − 非対称/鍵のペア (公開鍵と秘密鍵) で構成されます。PKI は 非対称暗号です。 <!--<tag/Digital Signatures/ A piece of data that is sent with an encrypted message that identifies the originator and verifies that it has not been altered.--> <tag/デジタル署名/暗号化されたメッセージとともに送信されるデータで、作成者の 証明をし、改竄されていないことを確認します。 <!--<tag/HTTPS/ The HyperText Transport Protocol (Secure), the standard encrypted communication mechanism on the World Wide Web. This is actually just HTTP over SSL.--> <tag/HTTPS/(安全な)ハイパーテキスト転送プロトコルで、World Wide Web における標準の暗号化された通信メカニズムです。これは、実際には単なる HTTP over SSL です。 <!--<tag/Message Digest/ A hash of a message, which can be used to verify that the contents of the message have not been altered in transit.--> <tag/メッセージダイジェスト/メッセージのハッシュで、メッセージの内容が転送中に 変更されていないことを確認するために利用されます。 <!--<tag/Non-repudiation/ A service that provides proof of the integrity and origin of data, both in an non-forgeable relationship, which can be verified by any third party at any time, or, an authentication that with high assurance can be asserted to be genuine.--> <tag/否認防止/(任意の第三者機関から任意の時に確認可能な) 偽造不可能な関係と、 本物であることが高い確度で断言できる認証との双方において、 データの無謬性と起源とが証明されているサービス。 <!--nakano 試訳です。ここも integrity は統一するほうが?--> <!--KURASHIKI そのまま頂きました--> <p> <!--A property achieved through cryptographic methods which prevents an individual or entity from denying having performed a particular action related to data (such as mechanisms for non-rejection or authority (origin); for proof of obligation, intent, or commitment, or for proof of ownership).--> これは暗号化手法によって達成された特質で、 個人あるいは実体に、データに関する特定の行動を取れないようにする (例えば否認禁止や認証(出自)の機構、義務・意志・委任などの証明、 あるいは所有権の証明など)。 <!--nakano これは名詞句のようですね。ちょっと日本語にするのは難しいけど...--> <!--KURASHIKI そのまま頂きます--> <!--<tag/OpenSSL/ The Open Source toolkit for SSL/TLS; see <url url="http://www.openssl.org/" name="http://www.openssl.org/">--> <tag/OpenSSL/オープンソースの SSL/TLS ツールキットです。 <url url="http://www.openssl.org/" name="http://www.openssl.org/"> 参照。 <!--<tag/Pass Phrase/ The word or phrase that protects private key files. It prevents unauthorized users from encrypting them. Usually it's just the secret encryption/decryption key used for Ciphers.--> <tag/パスフレーズ/秘密鍵ファイルを保護する単語や短文。認証されないユーザが、それらを暗号化に使うのを防ぎます。たいていは、サイファーに対して使われる、暗号化/復号化の秘密の鍵となります。 <!--nakano It's の It は key files を受けているんでしょう。 file"s" なので They で受けるべきだと思いますが。 --> <!--<tag/Plaintext/ The unencrypted text.--> <tag/平文/暗号化されていないテキスト。 <!--<tag/Private Key/ The secret key in a Public Key Cryptography system, used to decrypt incoming messages and sign outgoing ones.--> <tag/秘密鍵/公開鍵暗号システムにおける秘密の鍵で、届いたメッセージの復号化と、出ていくメッセージへの署名に使われます。 <!--<tag/Public Key/ The publicly available key in a Public Key Cryptography system, used to encrypt messages bound for its owner and to decrypt signatures made by its owner.--> <tag/公開鍵/公開鍵暗号システム上において、誰でも利用できる鍵で、その所有者宛てメッセージの暗号化と、その所有者による署名の復号化に使われます。 <!--<tag/Public Key Cryptography/ The study and application of asymmetric encryption systems, which use one key for encryption and another for decryption. A corresponding pair of such keys constitutes a key pair. Also called Asymmetric Cryptography.--> <tag/公開鍵暗号/ある鍵を暗号化、別の鍵を復号化に使う、非対称な暗号化システムの研究やアプリケーション。対応するこれらの鍵の組が鍵ペアを構成します。非対称暗号とも呼ばれます。 <!--nakano これはいいのでは--> <!--<tag/Secure Sockets Layer (SSL)/ A protocol created by Netscape Communications Corporation for general communication authentication and encryption over TCP/IP networks. The most popular usage is HTTPS, i.e. the HyperText Transfer Protocol (HTTP) over SSL.--> <tag/Secure Sockets Layer (SSL)/一般的な通信認証と TCP/IP ネットワーク越しの暗号化のために、 ネットスケープコミュニケーションズ社によって作成されたプロトコル。 最も有名な利用法は HTTPS、すなわち HTTP over SSL です。 <!--<tag/Session/ The context information of an SSL communication.--> <tag/セッション/SSL 通信におけるコンテキスト情報。 <!--<tag/SSLeay/ The original SSL/TLS implementation library developed by Eric A. Young <eay@aus.rsa.com>; see <url url="http://www.ssleay.org/" name="http://www.ssleay.org/">--> <tag/SSLeay/ Eric A. Young <eay@aus.rsa.com> が開発した、最初に SSL/TLS を実装したライブラリ。<url url="http://www.ssleay.org/" name="http://www.ssleay.org/"> 参照。 <!--<tag/Symmetric Cryptography/ The study and application of Ciphers that use a single secret key for both encryption and decryption operations.--> <tag/対称暗号法/暗号化と復号化の両方に、単一の秘密鍵を使う、研究やアプリケーション。 <!--<tag/Transport Layer Security (TLS)/ The successor protocol to SSL, created by the Internet Engineering Task Force (IETF) for general communication authentication and encryption over TCP/IP networks. TLS version 1 and is nearly identical with SSL version 3.--> <tag/トランスポート層セキュリティ (TLS)/SSL の後継プロトコルで、 一般的な通信認証と TCP/IP ネットワーク越しの暗号化のために、 インターネット技術評議会 (IETF) によって作成されました。 <!--(★and の訳出)とりあえず保留-->TLS のバージョン 1 は、SSL のバージョン 3 とほとんど同一です。 <!--nakano 原文の間違いっぽいですね --> <!--<tag/Uniform Resource Locator (URL)/ The formal identifier to locate various resources on the World Wide Web. The most popular URL scheme is http. SSL uses the scheme https--> <tag/ユニフォームリソースロケータ (URL)/World Wide Web 上の様々な リソースの位置を示す、正規の識別子。もっとも有名な URL のスキームは、 http です。SSL は https というスキームを用います。 <!--<tag/X.509/ An authentication certificate scheme recommended by the International Telecommunication Union (ITU-T) and used for SSL/TLS authentication.--> <tag/X.509/国際通信連合 (ITU-T) が推奨する認証証明のスキームで、 SSL/TLS の認証に用いられます。 <!--<tag/ITU-T/ Recommendation X.509 [CCI88c] specifies the authentication service for X.500 directories, as well as the X.509 certificate syntax. Directory authentication in X.509 can be carried out using either secret-key techniques or public-key techniques; the latter is based on public-key certificates. The standard does not specify a particular cryptographic algorithm, although an informative annex of the standard describes the RSA algorithm.--> <tag/ITU-T/X.509 [CCI88c] 勧告は、X.509 の証明記法だけでなく X.500 ディレクトリの認証サービスを定義します。X.509 のディレクトリ認証は、秘密鍵でも 公開鍵でも実装可能で、後者は公開鍵証明書に基づくものです。標準では、特定の 暗号化アルゴリズムは指定されていませんが、標準に附属する参考文書では、 RSA アルゴリズムについて説明がなされています。 </descrip> </article>