■レンタルサーバご利用参考資料
サーバご利用の参考にJF Project によるJF (Japanese FAQ)を掲載しています。
Linux JF(Japanese FAQ)Project.
JF は, Linux に関する解説文書・FAQ などを作成・収集・配布するプロジェクトです.
グリーンネット・トップページへ戻る
一覧に戻る
安全な RedHat Apache サーバの構築方法
Richard Sigle, Richard.sigle@equifax.com
0.1, 2001-02-06
KURASHIKI Satoru (ouka@fx.sakura.ne.jp)
0.1J, 2002-02-22
このガイドは、PKI と SSL を一緒に動かす方法を説明するように意図されて
います。安全なサーバを構築するためには、SSL プロトコルがどう機能してい
るかを理解する必要があります。
______________________________________________________________________
目次
1. このガイドの目的/範囲
1.1 Secure Sockets Layer (SSL) について
1.2 フィードバック
1.3 著作権と商標
1.4 謝辞
2. Secure Sockets Layer/Private Key Infrastructure への招待
2.1 SSL/PKI の信頼性
2.2 SSL はどう機能するのか
2.2.1 SSL ハンドシェイクプロトコル
2.2.2 セッション鍵 (対称鍵)
2.2.3 公開/秘密鍵のペア(非対称コード)
2.3 PKI の仕組み
2.4 証明書(x509 標準)
2.5 デジタル証明書の秘密鍵
2.6 デジタル証明書の公開鍵
2.7 証明書署名要求(CSR)
3. 証明書による作業
3.1 秘密鍵の作成
3.2 証明書署名要求の作成
3.3 自署証明書の作成
3.4 ウェブサーバへの証明書のインストール
4. Apache Server の設定
4.1 セキュアなヴァーチャルホストの定義
4.1.1 SSL Engine
4.1.2 SSLCertificateFile
4.1.3 SSLCertificateKeyFile
4.1.4 SSLCACertificateFile
4.2 証明書の例
4.2.1 サーバ証明書ファイル
4.2.2 証明書ファイルの内容
4.2.3 秘密鍵ファイル
4.2.4 秘密鍵ファイルの内容
4.3 Web サーバの再起動
5. トラブルシューティング
5.1 サーバは起動したように見えるが、セキュアサイトにアクセスできない
5.2 クライアントのブラウザが Certificate Name Check Warning を出す
5.3 クライアントのブラウザが、証明書が信頼されていない証明書発行機関によって署名されている、という警告を発する
5.4 SSLEngine on is an un-recognized command (Apache の起動時)
5.5 "PEM パスフレーズ" を忘れてしまい、どうやってそれを再設定するか知りたい。
6. 用語集
______________________________________________________________________
1. このガイドの目的/範囲
このガイドの目的は、RedHat Linux のユーザが Apache ウェブサーバを使っ
てサーバ(SSL)証明書をインストールするのを手助けすることです。目標は、
時間と、多くの場合お金を節約してくれる手順をはっきり示すことです！
最初に、 SSL プロトコルとデジタル証明書について知っておくべきことを説
明します。私の経験では、ModSSL と OpenSSL を使って Apache ウェブサーバ
を構築するのが、最も有益なソフトウェアの組み合わせです。OpenSSL は汎用
的な暗号化ライブラリで、SSL v2/v3 と TLS v1 プロトコルをサポートしてい
ます。 ModSSL は、Apache API モジュールで、Apache と OpenSSL 間のイン
ターフェイスとして動作するように作られています。最大の利益は、これら 3
つのパッケージがフリーであることです。
そして 4 章からは、鍵の生成と、ModSSL と OpenSSL を組みこんでコンパイ
ルされた RedHat-Apache サーバへの証明書のインストールを順を追って見て
いきます。 4 章の手順は、Apache と密接に関係している Stronghold や
Raven といった商用 SSL サーバのパッケージにも適用できるでしょう。
警告：私は、Equifax Secure Inc. という証明書発行機関のテクニカルサポー
ト技術者です。ですから、私は Equifax Secure の証明書を使いますし、例は
Equifax Secure の証明書をインストールに適合した形になっています。とは
いえ、手引きは他の証明書発行機関による証明書にも使えるはずです。この文
書を私が率先して書いたからといっても、Equifax Secure Inc. は、これらの
手順を使うことによって生じる何如なる結果についても、義務も責任も負いま
せん。
読者に対する私のコメントは、このスタイル(強調)です。.
例は普通のスタイルで示します。.
高度なコメントやアドバイスは、SGML ソース中のコメントとして書いてあり
ます。
1.1. Secure Sockets Layer (SSL) について
SSL は、TCP とアプリケーション層の間にある、プレゼンテーション層のサー
ビスです。これはプラットフォームやアプリケーションには依存しません。
SSL はクライアントとサーバ間のセキュアな通信チャネルを管理する役目を
持っています。 SSL はクライアントとサーバ間で転送されるデータを暗号化
する、強力な機構を提供します。
1.2. フィードバック
このガイドについてのコメントは、著者 (richard.sigle@equifax.com) にあ
てにお願いします。
1.3. 著作権と商標
Copyright (c) 2001 by Richard L. Sigle
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:
o Send your derivative work (in the most suitable format such as
sgml) to the 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.
o License the derivative work with this same license or use GPL.
Include a copyright notice and at least a pointer to the license
used.
o Give due credit to previous authors and major contributors.
If you're considering making a derived work other than a translation,
it's requested that you discuss your plans with the current
maintainer.
1.4. 謝辞
倦むことなく私のドラフトを読んで、アドバイスをくれた Tony Villasenor
に感謝を。 Tony がいなければ、この文書は書き上げることができなかったで
しょう。
2. Secure Sockets Layer/Private Key Infrastructure への招待
PKI は、公開鍵 (クライアントに送られます) と秘密鍵 (サーバ上に存在しま
す) からなる、非対称の鍵システムです。PKI は、クライアントとサーバの両
方が暗号化/復号化に同じ鍵を使う、対称の鍵システムとは異なります。
2.1. SSL/PKI の信頼性
クレジットカード情報や医療記録、法律文書、e-commerce アプリケーション
といった、最も機密に注意しなければならない処理の通信にも利用可能である
ように、という要求を満たすために SSL は設計されました。各アプリケー
ションは、機密性や処理される取引の価値によって、以下の特徴のどれを (あ
るいはすべてを) 使うか選択できます。
プライバシー
例えば、A から B へ伝達するために、メッセージが符号化されるとし
ます。A は B の公開鍵を使ってメッセージを暗号化します。こうする
と、B は自分の秘密鍵を使ってこのメッセージを復号化して読むことが
できる唯一の人物となります。しかし、A が自称している通りの人物で
あるかは定かではありません。
認証
A が自称している通りの人物であることを確かめるためには、保証され
た認証が必要です。これには少しばかり複雑な暗号化の過程が必要で
す。この場合、A から B へのメッセージは、最初に A の秘密鍵で、次
に B の公開鍵で暗号化されます。B はまず自分の秘密鍵で、ついで A
の公開鍵で復号化しなければなりません。これで、B は A が自称して
いる通りの人物だと確信できます。他の人は誰も A の秘密鍵で暗号化
したメッセージを作ることはできないのですから。 SSL はこれを、証
明書 (PKI) を使うことで達成しています。証明書は、− 証明書発行機
関 (CA)のような − 中立のサードパーティから発行され、証明された
相手の公開鍵に加えて、デジタル署名やタイムスタンプを含んでいま
す。正しい SSL ツールを使えば誰でも自署したデジタル証明書を作成
できますが、自署した証明書では、共通に敬意を払われている中立のサ
ードパーティが行う、批准の重みに欠けます。
無謬性
SSL においては、MAC (Message Authentication Code: メッセージ認証
コード) を必須のハッシュテーブル関数とともに使うことで無謬性が保
証されています。メッセージの生成時に、ハッシュ関数を使うことで
MAC が得られ、その結果がメッセージに追加されます。メッセージが受
信されると、メッセージに埋めこまれた MAC を受けとったメッセージ
から計算した新しい MACと比較することで、妥当性が検証されます。こ
れで、第三者によって変更されたメッセージはすぐに明らかになりま
す。
否認防止
否認防止は、オンラインのやりとりの間、両方の通信者をお互いから保
護します。これは、どちらかが、情報のうち特定の一部分を送らなかっ
た、と言うのを防ぎます。否認防止は、どちら側についても、既になさ
れたやりとりの内容を改変することを許しません。デジタル否認防止は
伝統的な感覚でいえば、契約書にサインするのと等価です。
2.2. SSL はどう機能するのか
SSL プロトコルは、2 つのサブプロトコルを含みます − SSL レコードプロト
コルと SSL ハンドシェイクプロトコルです。SSL レコードプロトコルはデー
タの伝送に使うフォーマットを定義します。SSL ハンドシェイクプロトコルに
は、 SSL レコードプロトコルの利用が含まれています。これは SSL 化された
サーバとクライアントが最初に SSL 接続を確立するときにやりとりする一連
のメッセージ交換に用いられます。このメッセージ交換は、以下の機能を容易
にするべく設計されています。
o サーバからクライアントへの認証。サーバ証明書は、証明書発行機関に
よって署名されており、証明書が壊れておらず、信頼の鎖が成立している
ことを保証します。
o クライアントとサーバが、双方がともにサポートしている暗号化アルゴリ
ズム、つまりサイファー(cipher)を選べるようにします。
o 任意で、サーバに対してクライアントを認証。
o 共有の秘密を生成するのに、公開鍵暗号技術を使います。
o 暗号化された SSL 接続を確立します。
2.2.1. SSL ハンドシェイクプロトコル
ハンドシェイクプロトコルは、クライアントとサーバの状態を調整するのに使
われます。ハンドシェイクの間、以下のイベントが発生します −
o クライアントとサーバの間で証明書が交換されます (非対称の鍵)。サーバ
は公開鍵をクライアントに送ります。サーバが証明書を使ってクライアン
トの認証を行うよう設定されているなら、クライアントは公開鍵をサーバ
に送ります。証明書の有効期限日を確認し、信頼された証明書発行機関の
デジタル署名をチェックします。有効期限日やデジタル署名が間違ってい
れば、ブラウザはユーザに警告を出します。ユーザはそれから証明書の保
持者を信頼することもできます。
o 次にクライアントはランダムな鍵 (対称鍵) を生成します。これらは暗号
化と MAC の計算に使われます。この鍵は、サーバの公開鍵で暗号化され、
サーバに送られます。この新しい対称鍵は、サーバのみが復号化できま
す。新しい対称鍵は、クライアントとサーバ間で送られるデータの暗号化
に使われます。
注： サーバ - ブラウザ間認証の後に対称鍵を使うことで、その後の処理
パフォーマンスが大幅に改善されます。
o メッセージの暗号化アルゴリズムと、無謬性のためのハッシュ関数とが交
渉 (negotiate) されます。この調整過程は、クライアントがサポートして
いるアルゴリズムの一覧をサーバに示し、次にサーバが双方で利用可能な
最も強い暗号を選ぶ、というように実行されます。選択された暗号化アル
ゴリズムとハッシュ関数の識別子は、現在のステータスの暗号方法スペッ
クフィールドに保存され、レコードプロトコルから利用されます。
o 以下のフィールドは全て、ハンドシェイクの間にセットされます −プロト
コルのバージョン、セッション ID、暗号の組、圧縮方法、それから 2 つ
のランダム値 ClientHello.random と ServerHello.random。
注： IP アドレスは、各 SSL 接続毎に必要になります。名前ベースのヴァー
チャルホストはアプリケーション層で解決されます。 SSL がアプリケーショ
ン層の下に存在していることを思い出しましょう。
2.2.2. セッション鍵 (対称鍵)
o 40 ビットは、もともと輸出用のものでした
o 56 ビットは DES で利用されています
o 64 ビット鍵 − CAST で利用されており、56 ビットより 256 倍強力です
o 80 ビット鍵 − CAST で利用されており、56 ビットの 16,000,000倍強力
です (現在の技術では、破ることはできません)
o 128 ビット鍵 − CAST や RC2 で使われており、現在も、予測できる未来
においても、網羅的に鍵を解読することは不可能です
2.2.3. 公開/秘密鍵のペア(非対称コード)
o 512-bit
o 768-bit
o 1024-bit
o 2048-bit
2.3. PKI の仕組み
クライアントとサーバは、それぞれ公開鍵と秘密鍵を持ちます (クライアント
が自分の証明書を持っており、それがサーバに要求されない限り、クライアン
トのブラウザは SSL のセッション用に鍵のペアをランダムに生成します)。
送信者は、自分の秘密鍵を使ってメッセージを暗号化します。これにより、
メッセージのソースが認証されます。結果の暗号は、受け手の公開鍵でもう一
度暗号化されます。これは、受け手のみが、自身の秘密鍵を使ってメッセージ
を最初に解読することができるようにすることで、機密性をもたらします。受
信者は、暗号化されたメッセージをさらに解読するため、送信者の公開鍵を使
います。送信者のみが自分の秘密鍵にアクセスできるので、受信者は暗号化さ
れたメッセージがその送信者からのものであるということを保証されます。
メッセージダイジェストは、関係者も第三者も、メッセージに何らかの改竄や
変更を施していないことを確認するのに利用されます。メッセージダイジェス
トは、メッセージにハッシュ関数 (指紋として知られる、秘密鍵の一部) を使
うことで得られます。ダイジェスト (署名と呼ばれます) はメッセージに添付
あるいは追加されます。署名の長さは (メッセージの長さに関らず) 一定で、
秘密鍵がもつメッセージダイジェストのタイプ (md5 は 128 ビット、 sha1
なら 160 ビット、など) によります。メッセージをたった 1 ビット変更した
だけでも署名の長さは変化するので、メッセージが変更されたことが証明され
ます。
2.4. 証明書(x509 標準)
デジタル証明書はインターネット上の存在を信頼できるようにします。デジタ
ル署名は、中立の第三者である証明書発行機関によって立証された、ユーザの
保証書を含みます。
数学的なアルゴリズムと値 (鍵) がデータを読めない形に暗号化するために使
われます。データの復号には 2 つめの鍵が用いられ、これは相補的なアルゴ
リズムと値を使います。 2 つの鍵は関連づけられた値を持っていなければな
らず、鍵のペア と呼ばれます。
注：ITU-T の勧告 X.509 [CCI88c] は X.509 証明書の記法のみならず、
X.500 ディレクトリへの認証サービスの仕様を定めています。証明書は、対象
の(ユーザの)名前とユーザの公開鍵とのつながりを認証するために、発行者に
よって署名されます。SSLv3 は 1994 年に採択されました。バージョン 2 と
3 の主な違いは、拡張フィールドが追加されたことです。このフィールドによ
り、単なる鍵と名前のつながりだけでなく、追加の情報を伝達することができ
るようになり、より柔軟になります。標準的な拡張では、対象と発行者の帰
属、認証ポリシー情報、鍵の利用制限などが含まれます。
X.509 証明書は、これらのフィールドで構成されます −
o バージョン
o シリアル番号
o 署名アルゴリズム ID
o 発行者名
o 有効期限
o 対象の(ユーザの)名前
o 対象の公開鍵情報
o 発行者固有の識別子(バージョン 2 と 3 のみ)
o 対象固有の識別子(バージョン 2 と 3 のみ)
o 拡張(バージョン 3 のみ)
o 上記フィールドについての署名
2.5. デジタル証明書の秘密鍵
秘密鍵は、デジタル証明書に埋めこまれてはいません。秘密鍵はどんなサーバ
情報ももちません。秘密鍵が持つのは暗号情報と指紋です。これは自分のシス
テム上でローカルに生成され、安全な環境のままでなければなりません。秘密
鍵が危険にさらされれば、加害者は、本質的にそのセキュリティシステムのコ
ードを手にしたことになります。クライアントとサーバ間の送信は、傍受さ
れ、解読され得ます。こういった弱点が、triple DES 技術を使って暗号化さ
れた秘密鍵を作ることが推奨されている理由です。するとファイルは暗号化さ
れ、パスワードで保護されます。これにより、正確なパスフレーズなしに使う
ことがほとんど不可能になります。
トランザクションのセキュリティは、その秘密鍵に依存します。この鍵が誤っ
た人手にわたったら、誰でも簡単にその合鍵を作って、セキュリティを破るた
めに使用できます。危うい鍵は、サーバへのメッセージが無法なハッカーに
よって傍受され、操作される事態を招きかねません。完全にセキュアなシステ
ムでは、詐称を検知でき、鍵の複製を妨害するようになっていなければなりま
せん。
2.6. デジタル証明書の公開鍵
公開鍵はデジタル証明書に埋めこまれており、セキュアな接続が要求された時
に、サーバからクライアントへ送られます。この過程により、証明書を使って
サーバの身元が確認されます。公開鍵は完全性、信憑性を検証し、秘密のデー
タ転送をするためにデータを暗号化するのにも使われます。
2.7. 証明書署名要求(CSR)
CSR は証明書発行機関が証明書を作成するのに必要となる情報を含むもので
す。 CSR は、秘密鍵に対して相補的なアルゴリズム、サーバの身元を証明す
る情報をもちます。この情報には、国、州、組織、一般名(ドメイン名)、連絡
先といった情報が含まれますが、限定されるわけではありません。
3. 証明書による作業
これ以降の節では、秘密鍵ファイルの作成、証明書署名要求、それから自署証
明書を含む手順をおさえます。証明書発行機関によって署名された証明書を入
手するつもりなら、証明書署名要求 (CSR) を作成する必要があります。ある
いは、自署証明書を作成することもできます。
3.1. 秘密鍵の作成
秘密鍵を作るには、OpenSSL ツールキットがインストールされていて、
Apache 用に設定されている必要があります。ここからの例では、デフォルト
の /usr/local/ssl/bin ディレクトリにある OpenSSL のコマンドラインツー
ルを使います。例では、OpenSSL のコマンドラインツールがあるディレクトリ
が $PATH に追加されていることを想定しています。
トリプル DES 暗号標準 (推奨) を使って秘密鍵を作るには、このコマンドを
使います −
openssl genrsa -des3 -out filename.key 1024
パスフレーズを入力し、また再入力するように求められます。トリプル DES
を使うことにしたなら、SSL サーバをコールドスタートで起動させる度にパス
ワードを求められます。(再起動コマンドを使う場合は、パスワードは聞かれ
ません。) 特にシステムを休みの間に起動せねばならない場合、このパスワー
ド入力がうざったいと思うかもしれません。また、システムは既に十分に堅牢
だと確信しているかもしれません。ですから、パスワード入力がないように選
択する (従ってトリプル DES 暗号化を使わずに) なら、以下のコマンドを実
行してください。逆に、単に 512 bit の鍵を作りたいなら、コマンドの最後
にある 1024 を削ってください。すると OpenSSL はデフォルトの 512 bit で
鍵を作ります。小さな鍵を使うと、少しばかり早くなりますが、安全性も低下
します。
秘密鍵をトリプル DES 暗号化なしで作成するには、このコマンドを使います
−
openssl genrsa -out filename.key 1024
既存の秘密鍵にパスワードを追加するには、このコマンドを使います −
openssl -in filename.key -des3 -out newfilename.key
既存の秘密鍵からパスワードを削除するには、このコマンドを使います −
openssl -in filename.key -out newfilename.key
注意：別途指定しなければ、秘密鍵はカレントディレクトリに作成されます。
これを取り扱うには 3 つの簡単な方法があります。OpenSSL がパスに入って
いれば、鍵ファイルを保存するために選んだディレクトリから実行することが
できます (Apache のインストールに RPM を使った場合のデフォルトは
/etc/httpd/conf/ssl.key で、ソースファイルからインストールしたのなら
/usr/local/apache/conf/ssl.key です)。別解は、鍵が作成されたディレクト
リから、正しいディレクトリへとファイルをコピーすることです。さらに、大
事なことを言い忘れましたが、コマンドの実行時にパスを指定することができ
ます (eg. openssl genrsa -out /etc/httpd/conf/ssl.key/filename.key
1024)。次に進む前に作業が終わっていれば、方法はどれでも構いません。
OpenSSL ツールキットについてのより詳しい情報は、ここ見てください −
OpenSSL Website
3.2. 証明書署名要求の作成
証明書発行機関によって署名された証明書を入手するには、証明書署名要求
(CSR) を作成する必要があります。目的は、秘密鍵を丸ごと送ったり、扱いの
難しい情報を危険にさらしたりすることなく、証明書を作成するに足る情報を
証明書発行機関に送ることです。CSR は、例えばドメイン名や地域情報といっ
た、証明書に含まれる情報ももっています。
o CSR を作るもとの秘密鍵を確認します。このコマンドを入力してください
−
openssl req -new -key filename.key -out filename.csr
o 地域情報、共通名 (ドメイン名)、組織情報などの入力を求められます。必
要とされる項目と、不適切なエントリの情報を、採用しようとしている CA
に問い合わせてください。
o CSR を CA の指示に従って送ります。
o 新しい証明書を待ちつつ、あるいは自署証明書を作成してください。自署
証明書は証明書発行機関から証明書を受けとるまで使用することができま
す。
注意：秘密鍵と要求(訳注:CSR)を同時に作成するには、次のコマンドを使いま
す。
openssl genrsa -des3 -out filename.key 1024
3.3. 自署証明書の作成
CA の署名した証明書を入手しようとしているなら、自署証明書を作る必要は
ありません。とはいえ、自署証明書の作成はたいへん簡単です。必要なのは、
秘密鍵とセキュアにしたいサーバの名前 (完全修飾ドメイン名) です。地域情
報や共通名 (ドメイン名)、組織情報などを訊ねられます。OpenSSL では、こ
こでかなりの自由がききます。証明書が正常に機能するために唯一必要な情報
は、共通名 (ドメイン名) です。これがなかったり、欠けたりしている
と、Certificate Name Check 警告をブラウザから受けることになります。
自署証明書を作成するには −
openssl req -new -key filename.key -x509 -out filename.crt
3.4. ウェブサーバへの証明書のインストール
これらの指示に従っていたら、今までのところ、ここまででは特に問題は起き
ていないはずです。CSR を証明書発行機関に送って、まだ証明書を受けとって
いないなら、ちょっと一休みしましょう！ 自署証明書を使っているか、証明
書を受けとりずみなら、次に進んでも構いません。
o 秘密鍵ファイルが、使うと決めた場所にあることを確認してください。続
く例は RedHat RPM によるインストールのデフォルト
値、/etc/httpd/conf/ssl.key に基いています。
o CA が署名した、あるいは自署の証明書が指定されたディレクトリにあるこ
とを確認してください。繰り返しますが、私は RPM のデフォルトである
/etc/httpd/conf/ssl.crt を使います。まだそこになければ、そこに配置
してください。
o もし、インストールする中間証明書 (またはルート証明書) があるなら、
それも /etc/httpd/conf/ssl.crt ディレクトリにコピーしてください。
o 次は、httpd.conf ファイルを編集する必要があります。次のステッ
プ、``Apache Server の設定'' に進む前に、このファイルのバックアップ
を作ってください。
4. Apache Server の設定
SSL をサポートするためには、Apache は追加の API モジュールを使うように
設定される必要があります。多くの SSL ソフトウェアパッケージが利用でき
ます。私の例では、ModSSL と OpenSSL 用に設定された Apache を元にしてい
ます。これらのプロダクトをサポートする数え切れないくらいのメーリングリ
ストやニュースグループがあります。 Apache ウェブサーバを元にしているい
くつかの商用 SSL パッケージにも、これらの手引きが有用だと思うかもしれ
ません。
いくつか頭に入れておくべきことがあります − 同じサーバに複数のヴァー
チャルホストをたてることができます。同じ IP アドレスで、名前ベースの
ヴァーチャルホストを多数たてることができます。同じ IP アドレスで、名前
ベースのヴァーチャルホストを多数と、セキュアなヴァーチャルホストを 1
つたてることもできます。ただし − 同じ IP アドレスで、複数のセキュアな
ヴァーチャルホストをたてることはできません。多くの人がこう訊ねるでしょ
う − 何故？ と。答えはこうです − SSL はアプリケーション層の下で機能
します。名前ベースのホストは、アプリケーション層までは定義されていませ
ん。
特に、同じ SOCKET (IP アドレス + ポート) について、複数のセキュアな
ヴァーチャルホストをたてることはできません。デフォルトでは、セキュアな
ホストはポート 443 を使います。ヴァーチャルホストが同じ IP アドレスで
異なるポート番号を使うことで、別のソケットを作成するように設定を変更す
ることはできます。この方法には数多くの不都合があります。一番明確な不都
合は、デフォルトポートを使っていない場合、セキュアサイトへのアクセスに
おいて、URL にポート番号を含めなくてはならないことです。
例えば：
o デフォルトポートを使うサイト、www.something.com
は、https://www.something.com でアクセスできます
o ポート 8888 を使うサイトでは、https://www.something.com:8888 でアク
セスできます。
もう一つの不都合は、たくさんのポートを使うと、ポートを嗅ぎまわるハッカ
ーにより機会を与えることになる、ということです。最後に、選んだポートが
何か他で使われていると、衝突問題が発生することになります。
4.1. セキュアなヴァーチャルホストの定義
ヴァーチャルホストの設置は、全く簡単です。セキュアなヴァーチャルホスト
を設定する基本を、検討していきます。
これらの例において、.crt と .key ファイル拡張子を使います。これは、様
々なファイルとの混乱を避ける、個人的な方法です。Apache を使うなら、好
きな拡張子を使えますし、あるいは拡張子なしにもできます。
セキュアなヴァーチャルホストは全て、通常は httpd.conf ファイルの末尾に
配置される、 と に包含される必要がありま
す。
セキュアなヴァーチャルホストの例です −
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
SSLOptions +StdEnvVars
SSLOptions +StdEnvVars
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"
SSL について最も重要なディレクティブは、SSLEngine on,
SSLCertificateFile, SSLCertificateKeyFile, それから多くの場合で
SSLCACertificateFile です。
4.1.1. SSL Engine
"SSLEngine on"− これは、SSL を開始するための ModSSL コマンドです。
4.1.2. SSLCertificateFile
SSLCertificateFile は、Apache に証明書ファイルの在処と、それがなんとい
う名前なのかを指示します。上の例では、"server.crt" が証明書ファイル名
として示されています。これは、Apache と一緒に ModSSL を設定した時に追
加されるデフォルトです。個人的には、デフォルトの名前を使うことはお勧め
しません。面倒なのをこらえて、証明書にサーバ名.crt (ドメイン名.crt) と
名付けてください。同じように、デフォルトの /etc/httpd/conf/ssl.crt や
/usr/local/apache/conf/ssl.crt とは別のディレクトリを使うこともできま
す。
4.1.3. SSLCertificateKeyFile
SSLCertificateKeyFile は、Apache に秘密鍵の名前とその在処を指示しま
す。ここで指定されたディレクトリは root のみが読み/書き権限を持ってい
る必要があります。他には誰もこのディレクトリにアクセスするべきではあり
ません。
4.1.4. SSLCACertificateFile
SSLCACertificateFile ディレクティブは、Apache に中間証明書の場所を指示
します。このディレクティブは、使用している CA によって必要だったり不必
要だったりします。この証明書が本質的に信頼の輪となります。
中間証明書 − 証明書発行機関は、あなたとほとんど同じ方法で証明書を得ま
す。これは、中間証明書として知られています。これは、基本的には中間証明
書の所持者が、いうものです。ウェブブラウザは、各リリースごとに更新され
る、"信頼できる" 証明発行機関のリストを持っています。証明書発行機関が
全く新しいなら、その中間証明書は、ブラウザの信頼できる CA リストには
入っていないでしょう。ほとんどの人が自分のブラウザをそう頻繁にアップデ
ートしたりしないという事実をこれと合わせると、こうなります − CA が自
動的に信頼できるものとして認識されるには、数年かかります。解決策は、
SSLCACertificateFile ディレクティブを使って、サーバに中間証明書をイン
ストールすることです。たいてい、"信頼された" CA は中間証明書を発行して
います。もしそうでなければ、SSLCertificateChainFile ディレクティブを使
わねばならないかも知れませんが、これはまずないことです。
4.2. 証明書の例
4.2.1. サーバ証明書ファイル
-----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-----
4.2.2. 証明書ファイルの内容
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
4.2.3. 秘密鍵ファイル
-----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-----
4.2.4. 秘密鍵ファイルの内容
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
4.3. Web サーバの再起動
ウェブサーバを再起動するスクリプトは、おそらく
/usr/local/sbinか、/usr/sbin (httpd というスクリプト名で)、あるいは
/usr/local/apache/bin (apachectl というスクリプト名で) にあるでしょ
う。 SSL を有効にしてサーバを起動していないなら、サーバを停止して、起
動させる必要があります。開始、再起動、停止のために、自分用のカスタマイ
ズしたスクリプトを書いても構いません。SSL エンジンが起動する限り、問題
はありません。
コマンドは −
httpd stop
httpd startssl
httpd restart
あるいは
apachectl stop
apachectl startssl
apachectl restart
5. トラブルシューティング
発生しうる、ありがちな問題をいくつか書いておきます。
5.1. サーバは起動したように見えるが、セキュアサイトにアクセスできない
error_log ファイルをチェックしてください。ヴァーチャルホストがエラーロ
グを書くように設定していないなら、考え直した方がいいかも知れません。例
示した SSL ヴァーチャルホストは、エラーログファイルに出力します。多
分、2, 3 の警告と、ログの最後にエラーがあり、基本的には秘密鍵が証明書
と一致しない、という内容でしょう。
例：
[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
上記のエラーメッセージを得たなら、問題は鍵と証明書が一致しないことで
す。デフォルトの server.keyファイルを使っていないことを確認してくださ
い。また、httpd.conf ファイルをチェックして、ディレクティブが正しい秘
密鍵と証明書を指しているかの確認もするべきです。
確認のため、秘密鍵と証明書の書式が正確で、お互いに対をなしていることを
調べることもできます。このためには、下のコマンドを使って秘密鍵をターミ
ナルウィンドウに復号化し、別のウィンドウで証明書を復号化してください。
比較するのは、鍵それぞれのモジュールと実体です。鍵のモジュールと実体が
証明書のそれと一致するならば、その証明書と鍵が正しく対になっているとい
えます。
全て失敗したなら、CSR か自署証明書の新しい秘密鍵を作成します。これを行
う前に、CA の再発行ポリシーを確認してください。再発行に課金されること
もあります。
証明書の内容を見る方法は −
openssl x509 -noout -text -in filename.crt
秘密鍵の内容を見る方法は −
openssl rsa -noout -text -in filename.key
5.2. クライアントのブラウザが Certificate Name Check Warning を出す
この一番の原因は、CSR を作成する時にドメイン名の始めに "www" をつけ忘
れていることです。仮想ホストに対して "ServerName" ディレクティブで定義
された名前は、証明書に示されたドメイン名と正確に一致しなければなりませ
ん。そうでないと、ブラウザはそれをクライアントに知らせようとします。例
外はワイルドカード証明書です。ワイルドカード証明書のドメイン名フィール
ドは *.somedomain.com のようになっています。これによって、1 つの証明書
で somedomain.com のサブドメインを複数扱えるようになります (例えば
host1.somedomain.com と host2.somedomain.com など)。
5.3. クライアントのブラウザが、証明書が信頼されていない証明書発行機関
によって署名されている、という警告を発する
自署証明書を使っていると、この警告が出ます。クライアントは、あなたの証
明書を信用するかしないかを選択できるのです。もし CA に署名された証明書
をもっているのに警告が出るのであれば、おそらくそれの中間証明書 (または
ルート証明書) をインストールする必要があります。
5.4. SSLEngine on is an un-recognized command (Apache の起動時)
このエラーメッセージは、Apache と一緒に ModSSL をコンパイルしなかった
場合に発生します。ヴァーチャルホストで SSL を使うのに、別のディレク
ティブを使う SSL パッケージもあります。別のディレクティブを使うパッケ
ージを使っている場合このエラーメッセージをまた見ることになります。
5.5. "PEM パスフレーズ" を忘れてしまい、どうやってそれを再設定するか
知りたい。
このパスフレーズを再設定する方法はありません。解決するには、パスフレー
ズを憶えておくか、新しい秘密鍵を作成するしかありません。そうすると、新
しい証明書を取得するか、新しい自署証明書を作成する必要がでてくるでしょ
う。
6. 用語集
認証
サーバやクライアント、ユーザといったネットワーク上の存在を、明確
に同一であると証明すること。SSL の文脈では、認証はサーバとクライ
アントにおける証明書の照合過程をいいます。
アクセス制御
ネットワーク領域へのアクセスを制限すること。通常 Apache の文脈で
は、ある URL へのアクセスを制限すること。
アルゴリズム
限られた手数で問題を解決するための明白な定式、あるいは規則の組。
暗号化のためのアルゴリズムは、通常 cipher と呼ばれます。(訳注：
本文では、cipher も暗号、などと訳してます。)
証明書
サーバやクライアントといったネットワークエンティティを認証するの
に使われる、データレコード。証明書は、その所有者 (subject と呼ば
れます) と署名をする証明書発行機関 (issuer と呼ばれます) に関す
る X.509 の情報断片、加えて所有者の秘密鍵と CA によって作成され
た署名を含みます。ネットワークエンティティはこれらの署名を検証す
るのに、 CA の証明書を使います。
認証機関 (CA)
信頼されている第三者機関で、ネットワークエンティティが安全な手段
で認証されるために、その証明書に署名するのが目的です。他のネット
ワークエンティティは署名をチェックして、 CA が証明書の運び手とし
て認証されていることを確認することができます。
証明書署名要求 (CSR)
認証機関に提出される署名されていない証明書で、その CA 証明書の秘
密鍵で署名されます。CSR は署名されることで真の証明書となります。
サイファ
データの暗号化のために使うアルゴリズムやシステム。例えば、DES,
IDEA, RC4 などです。(訳注：原文のミスと想定して訳に手を加えてい
ます)
暗号文
プレインテキストに暗号法を施した結果。
設定ディレクティブ
プログラムの挙動において、1 つ以上の側面を操作する設定命
令。Apache の文脈では、設定ファイルの最初のカラムにあらゆる命令
がきます。
暗号化 − 対称
クライアントとサーバが、データの暗号化と復号化に同じ鍵を用いま
す。
暗号化 − 非対称
鍵のペア (公開鍵と秘密鍵) で構成されます。PKI は非対称暗号です。
デジタル署名
暗号化されたメッセージとともに送信されるデータで、作成者の証明を
し、改竄されていないことを確認します。
HTTPS
(安全な)ハイパーテキスト転送プロトコルで、World Wide Web におけ
る標準の暗号化された通信メカニズムです。これは、実際には単なる
HTTP over SSL です。
メッセージダイジェスト
メッセージのハッシュで、メッセージの内容が転送中に変更されていな
いことを確認するために利用されます。
否認防止
(任意の第三者機関から任意の時に確認可能な) 偽造不可能な関係と、
本物であることが高い確度で断言できる認証との双方において、データ
の無謬性と起源とが証明されているサービス。
これは暗号化手法によって達成された特質で、個人あるいは実体に、デ
ータに関する特定の行動を取れないようにする (例えば否認禁止や認
証(出自)の機構、義務・意志・委任などの証明、あるいは所有権の証明
など)。
OpenSSL
オープンソースの SSL/TLS ツールキットです。
http://www.openssl.org/ 参照。
パスフレーズ
秘密鍵ファイルを保護する単語や短文。認証されないユーザが、それら
を暗号化に使うのを防ぎます。たいていは、サイファーに対して使われ
る、暗号化/復号化の秘密の鍵となります。
平文
暗号化されていないテキスト。
秘密鍵
公開鍵暗号システムにおける秘密の鍵で、届いたメッセージの復号化
と、出ていくメッセージへの署名に使われます。
公開鍵
公開鍵暗号システム上において、誰でも利用できる鍵で、その所有者宛
てメッセージの暗号化と、その所有者による署名の復号化に使われま
す。
公開鍵暗号
ある鍵を暗号化、別の鍵を復号化に使う、非対称な暗号化システムの研
究やアプリケーション。対応するこれらの鍵の組が鍵ペアを構成しま
す。非対称暗号とも呼ばれます。
Secure Sockets Layer (SSL)
一般的な通信認証と TCP/IP ネットワーク越しの暗号化のために、ネッ
トスケープコミュニケーションズ社によって作成されたプロトコル。最
も有名な利用法は HTTPS、すなわち HTTP over SSL です。
セッション
SSL 通信におけるコンテキスト情報。
SSLeay
Eric A. Young が開発した、最初に SSL/TLS を実
装したライブラリ。http://www.ssleay.org/
参照。
対称暗号法
暗号化と復号化の両方に、単一の秘密鍵を使う、研究やアプリケーショ
ン。
トランスポート層セキュリティ (TLS)
SSL の後継プロトコルで、一般的な通信認証と TCP/IP ネットワーク越
しの暗号化のために、インターネット技術評議会 (IETF) によって作成
されました。 TLS のバージョン 1 は、SSL のバージョン 3 とほとん
ど同一です。
ユニフォームリソースロケータ (URL)
World Wide Web 上の様々なリソースの位置を示す、正規の識別子。
もっとも有名な URL のスキームは、 http です。SSL は https という
スキームを用います。
X.509
国際通信連合 (ITU-T) が推奨する認証証明のスキームで、 SSL/TLS の
認証に用いられます。
ITU-T
X.509 [CCI88c] 勧告は、X.509 の証明記法だけでなく X.500 ディレク
トリの認証サービスを定義します。X.509 のディレクトリ認証は、秘密
鍵でも公開鍵でも実装可能で、後者は公開鍵証明書に基づくものです。
標準では、特定の暗号化アルゴリズムは指定されていませんが、標準に
附属する参考文書では、 RSA アルゴリズムについて説明がなされてい
ます。
一覧に戻る
グリーンネット・トップページへ戻る
|
