+How-To / チュートリアル
+
+Apache チュートリアル: .htaccess ファイル
+
+
+.htaccess ファイルはディレクトリ毎に設定を変更する方法を
+提供します。
+
+
+
+
+
+.htaccess ファイルとは何か/その使い方
+
+ .htaccess ファイル (「分散設定ファイル」) は
+ ディレクトリ毎に設定を変更する方法を提供します。ディレクティブの
+ 書かれたファイルをディレクトリに置くことで、そのディレクトリとその
+ サブディレクトリすべてにディレクティブを適用させることができます。
+
+ 注:
+ .htaccess ファイルを別の名前にしたい場合は、
+ AccessFileName ディレクティブを
+ 使って変更することができます。例えば、そのファイルを .config
+ という名前にしたい場合は、以下の設定をサーバ設定ファイルに入れることが
+ できます:
+
+
+ AccessFileName .config
+
+
+
+ 一般に、.htaccess ファイルの構文は
+ 主設定ファイル
+ と同じです。これらのファイルに書くことのできるディレクティブは AllowOverride ディレクティブにより決まります。
+ このディレクティブは、.htaccess ファイルに
+ 書かれたディレクティブの中で、、
+ どのディレクティブが適用されるかをカテゴリー単位で指定します。
+ .htaccess に書くことのできるディレクティブであれば、
+ 説明文書には「上書き」という項目があり、.htaccess に書くことができるように
+ なるための AllowOverride の値が指定されています。
+
+ 例えば、AddDefaultCharset ディレクティブの説明を
+ 見ると、.htaccess ファイルでの使用が許可されていることが
+ わかります。 (ディレクティブの概要の所にある「コンテキスト」と書かれている
+ 行を見てください。) 上書きと書かれている行には
+ FileInfo とあります。ですから、.htaccess 中の
+ このディレクティブが有効になるためには、少なくとも
+ AllowOverride FileInfo が設定されている必要があります。
+
+ 例:
+
+
+ | コンテキスト: |
+ サーバ設定ファイル,バーチャルホスト,ディレクトリ,.htaccess |
+
+
+
+ | 上書き: |
+ FileInfo |
+
+
+
+
+ あるディレクティブを .htaccess ファイルに書くことができるか
+ どうかわからないときは、そのディレクティブの説明を探して、".htaccess"
+ のための「コンテキスト」の行を調べてください。
+
+
+ いつ .htaccess ファイルを使う(使わない)か。
+
+ 一般的に、サーバの主設定ファイルにアクセスできない場合を除いて、
+ .htaccess ファイルの使用は極力避けてください。
+ 世の中には、例えば、ユーザ認証は常に .htaccess ファイルで
+ 行なわなければならない、という誤解が広まっていますが、まったくそんなことは
+ ありません。ユーザ認証の設定はサーバ主設定ファイルに書くことができ、
+ 実際、その方がより良い設定方法です。
+
+ .htaccess ファイルはコンテンツ提供者がディレクトリ毎の
+ 設定を行ないたいけれど、サーバシステムの root アクセス権限を持っていない
+ という場合にのみ使うべきものです。サーバ管理者が頻繁に設定変更を行ないたくは
+ ない、というときには個々のユーザが .htaccess ファイルを使って
+ 自分で設定の変更を行なうことを許可した方が良いときもあるでしょう。
+ これは特に、ISP が複数のユーザのサイトを一つのマシンでホストしていて、
+ 各ユーザが設定の変更をできるようにしたいようなときにあてはまります。
+
+ しかし、普通は可能であれば .htaccess ファイルの使用は
+ 避けてください。.htaccess ファイルに書こうと考えるような
+ すべての設定は、サーバの主設定ファイルの Directory セクションで同じように行なうことが
+ できます。
+
+ .htaccess ファイルの使用を避ける理由は主に二つあります。
+
+ 一つ目はサーバの性能の問題です。AllowOverride ディレクティブが
+ .htaccess ファイルの設定を許可している場合は、Apache は
+ 各ディレクトリで .htaccess ファイルを探します。
+ ですから、.htaccess ファイルを許可すると、実際に使用しているか
+ どうかに関わらず、性能の低下を招くことになります! また、.htaccess
+ ファイルは文書がリクエストされる度に読み込まれます。
+
+ さらに、Apache は適用すべきディレクティブを集めるために、すべての
+ 上位のディレクトリの .htaccess ファイルを探す必要があることにも
+ 注意してください。(ディレクティブが適用される方法を
+ 参照してください。)ですから、/www/htdocs/example にある
+ ファイルがリクエストされたときは、Apache は以下のファイルを調べます。
+
+
+ /.htaccess
+ /www/.htaccess
+ /www/htdocs/.htaccess
+ /www/htdocs/example/.htaccess
+
+
+ ですから、そのディレクトリのそれぞれのファイルへのアクセスに対して、
+ 上の例のファイルがまったく存在しないときでも、追加のファイルシステムの
+ アクセスが行なわれることになります。(これは、.htaccess が
+ / に対して有効になっているときの場合で、普通はそうなって
+ いないことに注意してください。)
+
+ 二つ目はセキュリティです。ユーザにサーバの設定を変更することを
+ 許可することになりますので、あなた自身が管理できない変更をされる
+ 恐れがあります。ユーザにこの特権を与えるのが良いのかどうか、十分
+ 検討してください。また、ユーザに与える権限が必要なものよりも少なすぎると、
+ 余分な技術サポート報告を受け取るようになる可能性が高いことにも
+ 注意してください。確実に、ユーザにどの程度の権限を与えたか明確に告げるように
+ してください。AllowOverride に
+ 何を設定したかということと、関連する文書を示すことで、
+ 後々の混乱をぐっと減らすことが
+ できます。
+
+ ところで、ディレクティブの書かれた .htaccess を
+ /www/htdocs/example に置くことと、同じディレクティブを
+ 主サーバ設定の Directory セクション
+ <Directory /www/htdocs/example> に書くことは
+ 完全に等価です:
+
+ /www/htdocs/example の .htaccess ファイル:
+
+ <code>/www/htdocs/example</code> の .htaccess ファイルの
+ 内容
+ AddType text/example .exm
+
+
+ <code>httpd.conf のセクション</code>
+ file
+ <Directory /www/htdocs/example>
+
+ AddType text/example .exm
+
+ </Directory>
+
+
+ しかし、この設定はサーバ設定ファイルに書いた方がパフォーマンスの
+ 低下が少なくなります。ファイルがリクエストされる度に
+ 読み込まれる代わりに、Apache の起動時に 1 回だけ読み込めば
+ よくなるからです。
+
+ AllowOverride ディレクティブの
+ 値を none に設定することで .htaccess ファイル
+ の使用を完全に無効にすることができます。
+
+
+ AllowOverride None
+
+
+
+ディレクティブの適用のされ方
+
+ .htaccess ファイルの設定ディレクティブは .htaccess
+ ファイルの存在するディレクトリと、そのサブディレクトリすべてに適用されます。
+ しかし、上の階層のディレクトリにも .htaccess ファイルが
+ 存在するかもしれないことを覚えておくことは大切です。ディレクティブは現れる
+ 順番に適用されます。ですから、あるディレクトリの .htaccess は
+ ディレクトリツリーのより上の階層の .htaccess ファイルの
+ 設定を上書きするかもしれません。そして、その .htaccess も
+ より上の階層で書かれたディレクティブを上書きしたり、主サーバ設定ファイル
+ そのものの設定を上書きしたりしているかもしれません。
+
+ 例:
+
+ ディレクトリ /www/htdocs/example1 に以下の内容の
+ .htaccess ファイルがあります:
+
+
+ Options +ExecCGI
+
+
+ (注: .htaccess
+ ファイルで "Options" ディレクティブが有効になるためには、
+ "AllowOverride Options" を有効にする必要があります。)
+
+ ディレクトリ /www/htdocs/example1/example2 には
+ 以下のような .htaccess ファイルがあります:
+
+
+ Options Includes
+
+
+ 二つめの .htaccess により、ディレクトリ
+ /www/htdocs/example1/example2 では CGI の実行は
+ 許可されません。これは、Options Includes のみが
+ 効力を持ち、それがすべての以前の設定を上書きするからです。
+
+
+認証の例
+
+ もし認証の方法を知るためにこの部分に直接来たのであれば、次のことを
+ 知っておくことが重要です。よくある誤解に、パスワード認証を行なうためには
+ .htaccess ファイルを使う必要がある、というものがあります。
+ これは正しくありません。主サーバ設定ファイルの Directory セクションに
+ 認証用のディレクティブを書く方が推奨される方法で、.htaccess
+ ファイルは主サーバ設定ファイルを変更できないときにのみ使用すべきです。
+ いつ .htaccess ファイルを使うべきで、いつ使うべきではないかに
+ ついては 上を参照してください。
+
+ 以上のことをふまえた上で、もし .htaccess の使用が
+ まだ必要だと思う場合は、次のようなものが望みのことをしてくれるかも
+ しれません。
+
+ .htaccess ファイルの内容:
+
+
+ AuthType Basic
+ AuthName "Password Required"
+ AuthUserFile /www/passwords/password.file
+ AuthGroupFile /www/passwords/group.file
+ Require Group admins
+
+
+ これらのディレクティブが有効になるためには、
+ AllowOverride AuthConfig が有効でなくてはならないことに
+ 注意してください。
+
+ 認証と承認については 認証チュートリアルを
+ 参照してください。
+
+
+SSI の例
+
+ もう一つの .htaccess ファイルのよくある利用法は
+ 特定のディレクトリで SSI を有効にすることです。これは、望みのディレクトリの
+ .htaccess ファイルに以下の設定ディレクティブを書くことで
+ 達成できます:
+
+
+ Options +Includes
+ AddType text/html shtml
+ AddHandler server-parsed shtml
+
+
+ これらのディレクティブが有効になるためには、
+ AllowOverride Options と AllowOverride
+ FileInfo が有効になっている必要があることに注意してください。
+
+ よりまとまった SSI の説明は SSI チュートリアルを
+ 参照してください。
+
+
+CGI の例
+
+ 最後に、特定のディレクトリで CGI プログラムの実行を許可したいことが
+ あるでしょう。これは以下の設定で行なうことができます:
+
+
+ Options +ExecCGI
+ AddHandler cgi-script cgi pl
+
+
+ もしくは、あるディレクトリのすべてのファイルが CGI プログラムと
+ みなされるようにしたいなら、以下の設定で実現することができます:
+
+
+ Options +ExecCGI
+ SetHandler cgi-script
+
+
+ これらのディレクティブが有効になるためには、
+ AllowOverride Options と AllowOverride
+ FileInfo が有効である必要があることに注意してください。
+
+ CGI プログラムと設定のよりまとまった説明は CGI チュートリアルを参照してください。
+
+
+
+問題解決
+
+ 設定ディレクティブを .htaccess ファイルに書いたけれども、
+ 期待した効果が得られないときには、いくつかの原因が考えられます。
+
+ 一番よくあることは、設定ディレクティブが考慮されるようには
+ AllowOverride が設定されていない
+ というものです。該当のファイルのスコープに AllowOverride None
+ が設定されていないことを確認してください。これを調べるための良い方法は、
+ .htaccess ファイルにごみを書いて、リロードすることです。
+ サーバのエラーが生成されないときは、ほぼ確実に AllowOverride
+ None が設定されている状態になっています。
+
+ そうではなく、文書をアクセスしようとしたときにエラーが発生している
+ ときは、Apache のエラーログを調べてください。.htaccess ファイルで
+ 使用されたディレクティブが許可されていない、ということを知らせている
+ 可能性が高いです。または、構文の間違いがあることを述べているかもしれません。
+ その場合にはまずそれを修正する必要があります。
+
+
+
+
diff --git a/docs/manual/howto/index.xml.ja b/docs/manual/howto/index.xml.ja
new file mode 100644
index 00000000000..279d5d17c3d
--- /dev/null
+++ b/docs/manual/howto/index.xml.ja
@@ -0,0 +1,100 @@
+
+
+
+
+
+
+
+
+How-To / チュートリアル
+
+ ユーザ毎のウェブディレクトリ
+
+
+複数のユーザのいるシステムでは、UserDir ディレクティブを使って
+ 各ユーザがホームディレクトリにウェブサイトを構築できるように設定することが
+ 可能です。URL http://example.com/~username/ を訪れた人は
+ "username" というユーザの UserDir ディレクティブで指定された
+ サブディレクトリからコンテンツを得ることになります。
+
+
+URL からファイルシステムへのマッピング
+
+
+
+
+ UserDir を使ってファイルのパスを設定する
+
+ UserDir ディレクティブは
+ ユーザ毎のコンテンツが読み込まれるディレクトリを指定します。
+ このディレクティブはいろいろ違った形式を取ることができます。
+
+ スラッシュで始まらないパスが与えられたときは、ユーザのホームディレクトリ
+ からの相対パスとみなされます。次の設定があったときに:
+
+
+ UserDir public_html
+
+
+ URL http://example.com/~rbowen/file.html は
+ パス /home/rbowen/public_html/file.html へ
+ 変換されます。
+
+ パスがスラッシュで始まるときは、ディレクトリパスはそのパスに
+ ユーザ名を加えたものからなります。次の設定のとき:
+
+
+ UserDir /var/html
+
+
+ URL http://example.com/~rbowen/file.html は
+ パス /var/html/rbowen/file.html へ変換されます。
+
+ アスタリスク (*) を含むパスが指定されたときは、アスタリスクを
+ ユーザ名で置換したものが使用されます。このような設定だと:
+
+
+ UserDir /var/www/*/docs
+
+
+ URL http://example.com/~rbowen/file.html は
+ パス /var/www/rbowen/docs/file.html へ変換されます。
+
+
+
+
+ この機能を使用できるユーザを制限する
+
+ UserDir のドキュメントに示されている構文を使うことで、
+ どのユーザがこの機能を使うことができるかを制限することができます:
+
+
+ UserDir enabled
+ UserDir disabled root jro fish
+
+
+ 上の設定は dissabled 文のユーザ以外のすべてのユーザに
+ 対して UserDir の機能を有効にします。同様にして、以下のように
+ 数名のユーザ以外に対してこの機能を無効にすることもできます:
+
+
+ UserDir disabled
+ UserDir enabled rbowen krietz
+
+
+ 他の例は UserDir
+ の説明を参照してください。
+
+
+
+
+ ユーザ毎の CGI ディレクトリ
+
+ それぞれのユーザに専用の cgi-bin ディレクトリを与えるために、
+ Directory
+ を使ってユーザのホームディレクトリの指定された領域に対して CGI を有効に
+ することができます。
+
+
+ <Directory /home/*/public_html/cgi-bin/>
+ Options ExecCGI
+ SetHandler cgi-script
+ </Directory>
+
+
+ そして、UserDir が
+ public_html に設定されていると仮定すると、
+ そのディレクトリの CGI プログラム example.cgi
+ は以下の様に呼び出されることができます:
+
+
+ http://example.com/~rbowen/cgi-bin/example.cgi
+
+
+
+
+
+ ユーザによる設定変更を許可
+
+ ユーザに彼らのウェブ空間でのサーバの設定の変更を許可する場合、
+ ユーザは .htaccess ファイルを使って設定を変更する必要があります。
+ AllowOverride の値を
+ ユーザが変更することを許可したいディレクティブに対して十分なものに
+ 設定していることを確認してください。この機能がどのようにして動作しているか
+ の詳細は .htaccess チュートリアル を読んで
+ ください。
+
+
+
+
diff --git a/docs/manual/mod/mod_cgid.xml.ja b/docs/manual/mod/mod_cgid.xml.ja
new file mode 100644
index 00000000000..2379b0a05f7
--- /dev/null
+++ b/docs/manual/mod/mod_cgid.xml.ja
@@ -0,0 +1,92 @@
+
+
+
+
+
+
+
+
+SSL/TLS
+
+ SSL/TLS 暗号化: はじめに
+
+
+
+標準規格の良い所は、たくさんの規格から選べるということだ。
+そして、もし本当にどの規格も気に入らなければ、
+一年待つだけで探していた規格が現れる。
+
+-- A. Tanenbaum, "Introduction to
+Computer Networks"
+
+
+
+入門ということで、この章は Web、HTTP、Apache に通じている
+読者向けですが、セキュリティ専門家向けではありません。
+SSL プロトコルの決定的な手引きであるつもりはありません。
+また、組織内の認証管理のための特定のテクニックや、
+特許や輸出規制などの重要な法的な問題についても扱いません。
+むしろ、更なる研究への出発点として色々な概念、定義、例を並べることで
+ mod_ssl のユーザに基礎知識を提供する事を目的としています。
+
+ここに示された内容は主に、原著者の許可の下
+The Open Group Research Institute の Frederick J. Hirsch
+ 氏の記事
+Introducing SSL and Certificates using SSLeay を基にしています。
+氏の記事は Web Security: A Matter of
+Trust, World Wide Web Journal, Volume 2, Issue 3, Summer 1997
+に掲載されました。
+肯定的な意見は Frederick Hirsch 氏
+ (元記事の著者) へ全ての苦情は Ralf S. Engelschall (
+mod_ssl の作者) へお願いします。
+[訳注: 訳については
+Apache ドキュメント翻訳プロジェクト
+へお願いします。]
+
+
+
+暗号化技術
+SSL を理解するには、暗号アルゴリズム、
+メッセージダイジェスト関数(別名: 一方向関数、ハッシュ関数)、
+電子署名などへの理解が必要です。
+これらの技術は本が丸ごと必要な題目で
+(例えば [AC96] を参照)、
+プライバシー、信用、認証などの技術の基礎となっています。
+
+
+暗号アルゴリズム
+ 例えば、アリスが送金のために銀行にメッセージを送りたいとします。
+ 口座番号や送金の金額が含まれるため、
+ アリスはそのメッセージを秘密にしたいと思います。
+ 解決方法の一つは暗号アルゴリズムを使って、メッセージを
+ 読ませたい人以外は読むことができない暗号化された
+ 形態に変えてしまうことです。
+ その形態になると、
+ メッセージは秘密の鍵によってのみ解釈することができます。
+ 鍵なしでは、メッセージは役に立ちません。
+ 良い暗号アルゴリズムは、侵入者が元のテキストを解読することを
+ 非常に難しくするため、努力が割に合わなくさせます。
+
+ 暗号アルゴリズムには
+ 従来型と公開鍵の二つの種類があります。
+
+
+ - 従来型暗号
+ - 対称暗号としても知られ、
+ 送信者と受信者が鍵を共有することが必要です。
+ 鍵とは、メッセージを暗号化したり復号するのに使われる秘密
+ の情報のことです。
+ もし、この鍵が秘密なら、送信者と受信者以外は誰もメッセージを読
+ むことができません。
+ もしも、アリスと銀行が秘密の鍵を知っているなら、
+ 彼らはお互いに秘密のメッセージを送ることができるでしょう。
+ ただし、事前に内密に鍵を選ぶという仕事は問題を含んでいます。
+
+ - 公開鍵暗号
+ - 非対称暗号としても知られ、
+ メッセージを暗号化することのできる二つの鍵
+ を使用するアルゴリズムを定義することで鍵のやり取りの問題を解決
+ します。
+ もし、ある鍵が暗号化に使われたなら、
+ もう片方の鍵で復号しなければいけません。
+ この方式によって、一つの鍵を公表して(公開鍵)、
+ もう片方を秘密にしておく(秘密鍵)だけで、
+ 安全なメッセージを受け取ることができます。
+
+
+ 誰もが暗号化されたメッセージを公開鍵によって暗号化
+ することができますが、秘密鍵の持ち主だけがそれを読むことが
+ できます。
+ この方法で、銀行の公開鍵を使って暗号化することで、
+ アリスは秘密のメッセージを送ることができます。
+ 銀行のみが復号することができます。
+
+
+
+メッセージダイジェスト
+ アリスはメッセージを秘密にすることができますが、
+ 誰かが例えば自分に送金するようにメッセージを変更したり、
+ 別のものに置き換えてしまうかもしれないという問題があります。
+ アリスのメッセージの信用を保証する方法の一つは、
+ メッセージの簡潔なダイジェストを作って、それも銀行に送るというものです。
+ メッセージを受け取ると銀行もダイジェストを作成し、
+ アリスが送ったものと比べます。もし一致したなら、
+ 受け取ったメッセージは無傷だということになります。
+
+ このような要約はメッセージダイジェスト、
+ 一方行関数、またはハッシュ関数と呼ばれます。
+ メッセージダイジェストは長い可変長のメッセージから
+ 短い固定長の表現を作るのに使われます。
+ ダイジェストアルゴリズムはメッセージから
+ 一意なダイジェストを生成するように作られています。
+ メッセージダイジェストはダイジェストから元のメッセージを
+ 判定するのがとても難しいようにできています。
+ また、同じ要約を作成する二つのメッセージを探すのは不可能です。
+ よって、同じ要約を使ってメッセージを置き換えるという
+ 可能性を排除しています。
+
+アリスへのもう一つの問題は、このダイジェストを安全に送る方法を探すことです。
+これができれば、メッセージの信用が保証されます。
+一つの方法はこのダイジェストに電子署名を含むことです。
+
+
+電子署名
+アリスが銀行にメッセージを送ったとき、銀行は、
+侵入者が彼女になりすまして彼女の口座への取引を申請していないか、
+メッセージが本当に彼女からのものか確実に分からなければいけません。
+アリスによって作成され、メッセージに含まれた
+電子署名がここで役に立ちます。
+
+電子署名はメッセージのダイジェストやその他の情報(処理番号など)を
+送信者の秘密鍵で暗号化することで作られます。
+誰もが公開鍵を使って署名を復号することができますが、
+署名者のみが秘密鍵を知っています。
+これは、彼らのみが署名しえたことを意味します。
+ダイジェストを電子署名に含むことは、
+その署名がそのメッセージのみに有効であることを意味します。
+これは、誰もダイジェストを変えて署名をすることができないため、
+メッセージの信用も保証します。
+
+侵入者が署名を傍受して後日に再利用するのを防ぐため
+電子署名には一意な処理番号が含まれます。
+これは、アリスがそんなメッセージは送っていないと言う詐欺
+から銀行を守ります。
+彼女だけが署名しえたからです。(否認防止)
+
+
+
+
+
+証明書
+アリスは秘密のメッセージを銀行に送り、
+署名をして、メッセージの信用を保証することができるおうになりましたが、
+通信している相手が本当に銀行なのか確かめなくてはいけません。
+これは、彼女が使う公開鍵が銀行の秘密鍵と対になっているものか、
+彼女は確かめなくてはいけないということを意味します。
+同様に、銀行はメッセージの署名が本当にアリスの署名か確認する必要が
+あります。
+
+もし両者に身元を証明し、公開鍵を確認し、また信頼された機関が署名
+した証明書があれば、両者とも通信相手について正しい相手だと
+確信することができます。
+そのような信頼された機関は認証局
+ (Certificate Authority または CA) と呼ばれ、
+証明書 (certificate) が認証 (authentication) に使われます。
+
+
+証明書の内容
+ 証明書は公開鍵と個人、サーバ、その他の主体の実在の身元を
+ 関連付けます。
+ 表1に示されるように証明対象の情報は
+ 身元証明の情報(識別名)と公開鍵が含まれます。
+ 証明書はまた、認証局の身元証明と署名、そして証明書の有効期間を
+ 含みます。
+ シリアルナンバーなどの認証局の管理上の情報や
+ その他の追加の情報が含まれているかもしれません。
+
+
+ 表1: 証明書情報
+
+
+
+ | 証明対象 |
+ 識別名、公開鍵 |
|---|
+ | 発行者 |
+ 識別名、公開鍵 |
|---|
+ | 有効期間 |
+ 開始日、失効日 |
|---|
+ | 管理情報 |
+ バージョン、シリアルナンバー |
|---|
+ | 拡張情報 |
+ 基本的な制約、ネットスケープフラッグ、その他 |
|---|
+
+
+
+ 識別名(ディスティングイッシュ・ネーム)は特定の状況における
+ 身分証明を提供するのに使われています。例えば、ある人は
+ 私用と会社とで別々の身分証明を持つかもしれません。
+
+ 識別名は X.509 標準規格 [X509] で定義されています。
+ X.509 標準規格は、項目、項目名、そして項目の略称を定義しています。(表
+ 2 参照)
+
+
+ 表 2: 識別名情報
+
+
+
+ | 識別名項目 |
+ 略称 |
+ 説明 |
+ 例 |
|---|
+ | Common Name (コモンネーム) |
+ CN |
+ 認証される名前
+ SSL接続するURL |
+ CN=www.example.com |
+ | Organization or Company (組織名) |
+ O |
+ 団体の正式英語組織名 |
+ O=Example Japan K.K. |
+ | Organizational Unit (部門名) |
+ OU |
+ 部署名など |
+ OU=Customer Service |
+ | City/Locality (市区町村) |
+ L |
+ 所在してる市区町村 |
+ L=Sapporo |
+ | State/Province (都道府県) |
+ ST |
+ 所在してる都道府県 |
+ ST=Hokkaido |
+ | Country(国) |
+ C |
+ 所在している国名の ISO コード
+ 日本の場合 JP
+ |
+ C=JP |
+
+
+
+ 認証局はどの項目が省略可能でどれが必須かの方針を定義する
+ かもしれません。項目の内容についても認証局や証明書のユーザからの
+ 要件があるかもしれません。
+ 例えば、ネットスケープのブラウザはサーバの証明書の
+ Common Name (コモンネーム)がサーバのドメイン名の
+ *.example.com
+ というようなワイルドカードのパターンにマッチすること
+ を要求します。
+
+ バイナリ形式の証明書は ASN.1 表記法
+ [X208] [PKCS] で
+ 定義されています。
+ この表記法は内容をどのように記述するかを定義し、
+ 符号化の規定がこの情報がどのようにバイナリ形式に変換されるかを
+ 定義します。
+ 証明書のバイナリ符号化は Distinguished Encoding
+ Rules (DER) で定義され、それはより一般的な Basic Encoding Rules
+ (BER) に基づいています。
+ バイナリ形式を扱うことのできない送信では、
+ バイナリ形式は Base64 符号化 [MIME] で
+ ASCII 形式に変換されることがあります。
+ このように符号化され、以下の例に示されるように区切り行に
+ 挟まれたものは PEM 符号化されたと言います。
+ (PEM の名前は "Privacy Enhanced Mail" に由来します)
+
+
+ PEM 符号化された証明書の例 (example.crt)
+ -----BEGIN CERTIFICATE-----
+MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx
+FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG
+A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv
+cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz
+bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL
+MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h
+a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl
+cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN
+AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
+gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b
+vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa
+lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV
+HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB
+gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt
+2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7
+dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ==
+-----END CERTIFICATE-----
+
+
+
+
+認証局
+ まず証明書の申請の情報を確認することで、
+ 認証局は秘密鍵の持ち主の身元を保証します。
+ 例えば、アリスが個人証明書を申請したとすると、
+ 認証局はアリスが証明書の申請が主張する通りの
+ 人物だということを確認しなくてはいけません。
+
+
+ 証明書階層構造
+ 認証局は他の認証局への証明書を発行することができます。
+ 未知の証明書を調べる時に、アリスはその証明書の発行者
+ に自信が持てるまで、発行者の証明書を
+ その上位階層の認証局をたどって調べる必要があります。
+ 「悪質な」証明書の危険性を減らすため、
+ 彼女は限られた連鎖の発行者のみ信頼するように
+ 決めることもできます。
+
+
+
+ 最上位認証局の作成
+ 前に述べたように、全ての証明書について、
+ 最上位の認証局(CA)までそれぞれの発行者が
+ 対象の身元証明の有効性を明らかにする必要があります。
+ 問題は、誰がその最上位の認証機関の証明書を保証するのか、
+ ということです。
+ このような場合に限り、証明書は「自己署名」されます。
+ つまり、証明書の発行者と証明対象が同じということになります。
+ その結果、自己署名された証明書を信用するには
+ 細心の注意が必要です。
+ 最上位認証局が公開鍵を広く公表することで、
+ その鍵を信頼するリスクを低くすることができます。
+ もし、他人がその認証局になりすました時に、それが露見しや
+ すいからです。
+ 多くのブラウザは有名な認証局を信頼するように
+ 設定されています。
+
+ Thawte
+ や VeriSign
+ のような多くの会社が認証局として開設しました。
+ このような会社は以下のサービスを提供します:
+
+
+ - 証明書申請の確認
+ - 証明書申請の処理
+ - 証明書の発行と管理
+
+
+ 自分で認証局を作ることも可能です。
+ インターネット環境では危険ですが、
+ 個人やサーバの身元証明が簡単に行える組織の
+ イントラネット内では役に立つかもしれません。
+
+
+
+ 証明書管理
+ 認証局の開設は徹底した管理、技術、運用の体制を必要とする
+ 責任のある仕事です。
+ 認証局は証明書を発行するだけでなく、
+ 管理もしなければなりません。
+ 具体的には、証明書がいつまで有効かを決定し、更新し、
+ また既に発行されたが失効した証明書のリスト
+ (Certificate Revocation Lists または CRL)
+ を管理しなければいけません。
+ 例えば、アリスが会社から社員として証明書を与えられたとします。
+ そして、アリスが会社を辞めるときには証明書を取り消さなければ
+ いけないとします。
+ 証明書は次々と人に渡されていくものなので、
+ 証明書そのものから、それが取り消されたか判断することは
+ 不可能です。
+ よって、証明書の有効性を調べるときには、
+ 認証局に連絡して CRL を照合する必要があります。
+ 普通この過程は自動化されているものではありません。
+
+ 注意
+ デフォルトでブラウザに設定されていない認証局を使った場合、
+ 認証局の証明書をブラウザに読み込んで、
+ ブラウザがその認証局によって署名されたサーバの証明書を
+ 有効化する必要があります。
+ 一度読み込まれると、その認証局によって署名された全ての
+ 証明書を受け入れるため、危険を伴います。
+
+
+
+
+
+
+
+
+Secure Sockets Layer (SSL)
+Secure Sockets Layer プロトコルは信頼性のあるコネクション型の
+ネットワーク層のプロトコル(例えば、TCP/IP)と
+アプリケーション層のプロトコル(例えば、HTTP)
+の間に置くことができます。
+SSL は、相互認証によってサーバとクライアント間の安全な通信を、
+電子署名によってデータの完全性を、
+そして暗号化によってプライバシを提供します。
+
+SSL プロトコルは暗号化、ダイジェスト、電子署名について、
+様々なアルゴリズムをサポートするようにできています。
+こうすることで、法や輸出の規制を考慮に入れて、サーバに合わせた
+アルゴリズムを選ぶことができ、また、新しいアルゴリズムを
+利用していくことも可能にしています。
+アルゴリズムの選択はプロトコルセッション開始時に
+サーバとクライアント間で取り決められます。
+
+
+表4: SSL プロトコルのバージョン
+
+
+
+ | バージョン |
+ 出典 |
+ 説明 |
+ ブラウザのサポート |
|---|
+ | SSL v2.0 |
+ Vendor Standard (Netscape Corp. より) [SSL2] |
+ 実装が現存する初めての SSL プロトコル |
+ - NS Navigator 1.x/2.x
+ - MS IE 3.x
+ - Lynx/2.8+OpenSSL |
+ | SSL v3.0 |
+ Expired Internet Draft (Netscape Corp. より) [SSL3] |
+ 特定のセキュリティ攻撃を防ぐための改訂、
+ 非RSA 暗号の追加、証明書階層構造のサポート |
+ - NS Navigator 2.x/3.x/4.x
+ - MS IE 3.x/4.x
+ - Lynx/2.8+OpenSSL |
+ | TLS v1.0 |
+ Proposed Internet Standard (IETF より) [TLS1] |
+ MAC レイヤを HMAC へ更新、ブロック暗号の block
+ padding、メッセージ順序の標準化、警告文の充実などのため
+ SSL 3.0 を改訂。 |
+ - Lynx/2.8+OpenSSL |
+
+
+
+表4に示されるとおり、SSL プロトコルには
+いくつものバージョンがあります。
+表にも書かれているように、SSL 3.0 の利点の一つは
+証明書階層構造をサポートすることです。
+この機能によって、サーバは自分の証明書に加えて、
+発行者の証明書をブラウザに渡すことができます。
+証明書階層構造によって、
+ブラウザに発行者の証明書が直接登録されていなくても、
+階層の中に含まれていれば、
+ブラウザはサーバの証明書を有効化することができます。
+SSL 3.0 は現在 Internet Engineering Task Force (IETF)
+によって開発されている Transport Layer Security
+[TLS] プロトコル標準規格の基礎となっています。
+
+
+セッションの確立
+ 図1で示されるように、
+ セッションの確立はクライアントとサーバ間の
+ ハンドシェークシークエンスによって行なわれます。
+ サーバが証明書を提供するか、クライアントの証明書をリクエストするか
+ というサーバの設定により、このシークエンスは異なるものとなります。
+ 暗号情報の管理のために、追加のハンドシェーク過程が必要になる
+ 場合もありますが、この記事では
+ よくあるシナリオを手短に説明します。
+ 全ての可能性についは、SSL 仕様書を参照してください。
+
+ 注意
+ 一度 SSL セッションが確立すると、セッションを再利用することで、
+ セッションを開始するための多くの過程を繰り返すという
+ パフォーマンスの損失を防ぎます。
+ そのため、サーバは全てのセッションに一意なセッション識別名を
+ 割り当て、サーバにキャッシュし、クライアントは次回から
+ (識別名がサーバのキャッシュで期限切れになるまでは)
+ ハンドシェークなしで接続することができます。
+
+
+
+ 
+ 図1: SSL
+ ハンドシェークシークエンス概略
+
+ サーバとクライアントで使われる
+ ハンドシェークシークエンスの要素を以下に示します:
+
+
+ - データ通信に使われる暗号スイートの取り決め
+ - クライアントとサーバ間でのセッション鍵の確立と共有
+ - オプションとして、クライアントに対するサーバの認証
+ - オプションとして、サーバに対するクライアントの認証
+
+
+ 第一ステップの暗号スイート取り決めによって、
+ サーバとクライアントはそれぞれにあった
+ 暗号スイートを選ぶことができます。
+ SSL3.0 プロトコルの仕様書は 31 の暗号スイートを定義しています。
+ 暗号スイートは以下のコンポーネントにより定義されています:
+
+
+ - 鍵の交換手段
+ - データ通信の暗号術
+ - Message Authentication Code (MAC) 作成のための
+ メッセージダイジェスト
+
+
+ これらの三つの要素は以下のセクションで説明されています。
+
+
+
+鍵の交換手段
+ 鍵の交換手段はアプリケーションのデータ通信に使われ、
+ 共有される対称暗号鍵をどのようにがクライアントとサーバで
+ 取り決めるかを定義します。
+ SSL 2.0 は RSA 鍵交換しか使いませんが、
+ SSL 3.0 は証明書が使われるときは RSA 鍵交換を使い、
+ 証明書が無く、クライアントとサーバの事前の通信が無い場合は
+ Diffie-Hellman 鍵交換を使う
+ など様々な鍵交換アルゴリズムをサポートします。
+
+ 鍵の交換方法における一つの選択肢は電子署名です。
+ 電子署名を使うかどうか、また、
+ どの種類の署名を使うかという選択があります。
+ 秘密鍵で署名することで共有鍵を生成すし、情報交換する時の
+ マン・イン・ザ・ミドル攻撃を防ぐことができます。
+ [AC96, p516]
+
+
+
+データ通信の暗号術
+ SSL はセッションのメッセージの暗号化に前述した
+ 従来型暗号(対称暗号)を用います。
+ 暗号化しないという選択肢も含め九つの選択肢があります:
+
+
+ - 暗号化なし
+ - ストリーム暗号
+
+ - 40-bit 鍵での RC4
+ - 128-bit 鍵での RC4
+
+ - CBC ブロック暗号
+
- 40 bit 鍵での RC2
+ - 40 bit 鍵での DES
+ - 56 bit 鍵での DES
+ - 168 bit 鍵での Triple-DES
+ - Idea (128 bit 鍵)
+ - Fortezza (96 bit 鍵)
+
+
+
+ ここでの CBC とは暗号ブロック連鎖 (Cipher Block Chaining)
+ の略で、一つ前の暗号化された暗号文の一部が
+ ブロックの暗号化に使われることを意味します。
+ DES はデータ暗号化標準規格 (Data Encryption Standard)
+ [AC96, ch12] の略で、
+ DES40 や 3DES_EDE を含むいくつもの種類があります。
+ Idea は最高なものの一つで、暗号術的には現在ある中で
+ 最も強力なものです。
+ RC2 は RSA DSI による独占的なアルゴリズムです。
+ [AC96,
+ ch13]
+
+
+
+ダイジェスト関数
+
+ ダイジェスト関数の選択はレコードユニットからどのようにダイジェストが生成されるかを決定します。
+ SSL は以下をサポートします:
+
+
+ - ダイジェストなし
+ - MD5 (128-bit ハッシュ)
+ - Secure Hash Algorithm (SHA-1) (160-bit ハッシュ)
+
+
+ メッセージダイジェストは Message Authentication Code (MAC)
+ の生成に使われ、メッセージと共に暗号化され、メッセージの信用を
+ 提供し、リプレイ攻撃を防ぎます。
+
+
+
+ハンドシェークシークエンスプロトコル
+ ハンドシェークシークエンスは三つのプロトコルを使います:
+
+
+ - SSL ハンドシェークプロトコルは
+ クライアントとサーバ間での SSL セッションの確立に使われます。
+ - SSL 暗号仕様変更プロトコルは
+ セッションでの暗号スイートの取り決めに使われます。
+ - SSL 警告プロトコルは
+ クライアントサーバ間で SSL エラーを伝達するのに使われます。
+
+
+ 三つのプロトコルは、アプリケーションプロトコルデータとともに、
+ 図2に示すとおり SSL レコードプロトコル
+ でカプセル化されます。
+ カプセル化されたプロトコルはデータを検査しない
+ 下層のプロトコルによってデータとして伝達されます。
+ カプセル化されたプロトコルは下層のプロトコルに関して一切関知しません。
+
+
+ 
+ 図2: SSL プロトコルスタック
+
+
+
+ レコードプロトコルによる SSL コントロールプロトコルのカプセル化は、
+ アクティブなセッションの二回目の通信があった場合、
+ コントロールプロトコルが安全であることを意味します。
+ 既にセッションが無い場合は、Null 暗号スイートが使われ、
+ 暗号化は行なわれず、セッションが確立するまでは
+ ダイジェストも無い状態となります。
+
+
+
+データ通信
+ 図3に示される SSL レコードプロトコル
+ はクライアントとサーバ間のアプリケーションや
+ SSL コントロールデータの通信に使われます。
+ このデータはより小さいユニットに分けられたり、
+ いくつかの高級プロトコルをまとめて一ユニットとして通信が
+ 行なわれることもあります。
+ データを圧縮し、ダイジェスト署名を添付して、
+ これらのユニットを暗号化したのち、ベースとなっている
+ 信頼性のあるトランスポートプロトコルを用いるかもしれません。
+ (注意: 現在メジャーな SLL 実装で圧縮をサポートしているものはありません)
+
+
+ 
+ 図 3: SSL レコードプロトコル
+
+
+
+
+HTTP 通信の安全化
+ よくある SSL の使い方はブラウザとウェブサーバ間の HTTP 通信
+ の安全化です。
+ これは、従来の安全ではない HTTP の使用を除外するものではありません。
+ 安全化されたものは主に SSH 上の普通の HTTP で、HTTPS と呼ばれます。
+ 大きな違いは、URL スキームに http の代わりに https
+ を用い、サーバが別のポートを使うことです (デフォルトでは443)。
+ これが主に mod_ssl が Apache ウェブサーバに提供する機能です。
+
+
+
+
+
+参考文献
+
+- [AC96]
+- Bruce Schneier,
Applied Cryptography
, 2nd Edition, Wiley,
+1996. See http://www.counterpane.com/ for various other materials by Bruce
+Schneier.
+
+- [X208]
+- ITU-T Recommendation X.208,
Specification of Abstract Syntax Notation
+One (ASN.1)
, 1988. See for instance http://www.itu.int/rec/recommendation.asp?type=items&lang=e&parent=T-REC-X.208-198811-I.
+
+
+- [X509]
+- ITU-T Recommendation X.509,
The Directory - Authentication
+Framework
. See for instance http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-X.509.
+
+
+- [PKCS]
+Public Key Cryptography Standards (PKCS)
,
+RSA Laboratories Technical Notes, See http://www.rsasecurity.com/rsalabs/pkcs/.- [MIME]
+- N. Freed, N. Borenstein,
Multipurpose Internet Mail Extensions
+(MIME) Part One: Format of Internet Message Bodies
, RFC2045.
+See for instance http://ietf.org/rfc/rfc2045.txt.
+
+- [SSL2]
+- Kipp E.B. Hickman,
The SSL Protocol
, 1995. See http://www.netscape.com/eng/security/SSL_2.html.
+
+- [SSL3]
+- Alan O. Freier, Philip Karlton, Paul C. Kocher,
The SSL Protocol
+Version 3.0
, 1996. See http://www.netscape.com/eng/ssl3/draft302.txt.
+
+- [TLS1]
+- Tim Dierks, Christopher Allen,
The TLS Protocol Version 1.0
,
+1999. See http://ietf.org/rfc/rfc2246.txt.
+
+
+
+
+
diff --git a/modules/loggers/mod_log_forensic.dsp b/modules/loggers/mod_log_forensic.dsp
new file mode 100644
index 00000000000..7058215670d
--- /dev/null
+++ b/modules/loggers/mod_log_forensic.dsp
@@ -0,0 +1,128 @@
+# Microsoft Developer Studio Project File - Name="mod_log_forensic" - Package Owner=<4>
+# Microsoft Developer Studio Generated Build File, Format Version 6.00
+# ** DO NOT EDIT **
+
+# TARGTYPE "Win32 (x86) Dynamic-Link Library" 0x0102
+
+CFG=mod_log_forensic - Win32 Release
+!MESSAGE This is not a valid makefile. To build this project using NMAKE,
+!MESSAGE use the Export Makefile command and run
+!MESSAGE
+!MESSAGE NMAKE /f "mod_log_forensic.mak".
+!MESSAGE
+!MESSAGE You can specify a configuration when running NMAKE
+!MESSAGE by defining the macro CFG on the command line. For example:
+!MESSAGE
+!MESSAGE NMAKE /f "mod_log_forensic.mak" CFG="mod_log_forensic - Win32 Release"
+!MESSAGE
+!MESSAGE Possible choices for configuration are:
+!MESSAGE
+!MESSAGE "mod_log_forensic - Win32 Release" (based on "Win32 (x86) Dynamic-Link Library")
+!MESSAGE "mod_log_forensic - Win32 Debug" (based on "Win32 (x86) Dynamic-Link Library")
+!MESSAGE
+
+# Begin Project
+# PROP AllowPerConfigDependencies 0
+# PROP Scc_ProjName ""
+# PROP Scc_LocalPath ""
+CPP=cl.exe
+MTL=midl.exe
+RSC=rc.exe
+
+!IF "$(CFG)" == "mod_log_forensic - Win32 Release"
+
+# PROP BASE Use_MFC 0
+# PROP BASE Use_Debug_Libraries 0
+# PROP BASE Output_Dir "Release"
+# PROP BASE Intermediate_Dir "Release"
+# PROP BASE Target_Dir ""
+# PROP Use_MFC 0
+# PROP Use_Debug_Libraries 0
+# PROP Output_Dir "Release"
+# PROP Intermediate_Dir "Release"
+# PROP Ignore_Export_Lib 0
+# PROP Target_Dir ""
+# ADD BASE CPP /nologo /MD /W3 /O2 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /FD /c
+# ADD CPP /nologo /MD /W3 /Zi /O2 /I "../../include" /I "../../srclib/apr/include" /I "../../srclib/apr-util/include" /I "../../server" /D "NDEBUG" /D "WIN32" /D "_WINDOWS" /Fd"Release\mod_log_forensic_src" /FD /c
+# ADD BASE MTL /nologo /D "NDEBUG" /win32
+# ADD MTL /nologo /D "NDEBUG" /mktyplib203 /win32
+# ADD BASE RSC /l 0x409 /d "NDEBUG"
+# ADD RSC /l 0x409 /d "NDEBUG"
+BSC32=bscmake.exe
+# ADD BASE BSC32 /nologo
+# ADD BSC32 /nologo
+LINK32=link.exe
+# ADD BASE LINK32 kernel32.lib /nologo /subsystem:windows /dll /machine:I386 /out:"Release/mod_log_forensic.so" /base:@..\..\os\win32\BaseAddr.ref,mod_log_forensic.so
+# ADD LINK32 kernel32.lib /nologo /subsystem:windows /dll /incremental:no /debug /machine:I386 /out:"Release/mod_log_forensic.so" /base:@..\..\os\win32\BaseAddr.ref,mod_log_forensic.so /opt:ref
+
+!ELSEIF "$(CFG)" == "mod_log_forensic - Win32 Debug"
+
+# PROP BASE Use_MFC 0
+# PROP BASE Use_Debug_Libraries 1
+# PROP BASE Output_Dir "Debug"
+# PROP BASE Intermediate_Dir "Debug"
+# PROP BASE Target_Dir ""
+# PROP Use_MFC 0
+# PROP Use_Debug_Libraries 1
+# PROP Output_Dir "Debug"
+# PROP Intermediate_Dir "Debug"
+# PROP Ignore_Export_Lib 0
+# PROP Target_Dir ""
+# ADD BASE CPP /nologo /MDd /W3 /GX /Zi /Od /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /FD /c
+# ADD CPP /nologo /MDd /W3 /GX /Zi /Od /I "../../include" /I "../../srclib/apr/include" /I "../../srclib/apr-util/include" /I "../../server" /D "_DEBUG" /D "WIN32" /D "_WINDOWS" /Fd"Debug\mod_log_forensic_src" /FD /c
+# ADD BASE MTL /nologo /D "_DEBUG" /win32
+# ADD MTL /nologo /D "_DEBUG" /mktyplib203 /win32
+# ADD BASE RSC /l 0x409 /d "_DEBUG"
+# ADD RSC /l 0x409 /d "_DEBUG"
+BSC32=bscmake.exe
+# ADD BASE BSC32 /nologo
+# ADD BSC32 /nologo
+LINK32=link.exe
+# ADD BASE LINK32 kernel32.lib /nologo /subsystem:windows /dll /incremental:no /debug /machine:I386 /out:"Debug/mod_log_forensic.so" /base:@..\..\os\win32\BaseAddr.ref,mod_log_forensic.so
+# ADD LINK32 kernel32.lib /nologo /subsystem:windows /dll /incremental:no /debug /machine:I386 /out:"Debug/mod_log_forensic.so" /base:@..\..\os\win32\BaseAddr.ref,mod_log_forensic.so
+
+!ENDIF
+
+# Begin Target
+
+# Name "mod_log_forensic - Win32 Release"
+# Name "mod_log_forensic - Win32 Debug"
+# Begin Source File
+
+SOURCE=.\mod_log_forensic.c
+# End Source File
+# Begin Source File
+
+SOURCE=.\mod_log_forensic.rc
+# End Source File
+# Begin Source File
+
+SOURCE=..\..\build\win32\win32ver.awk
+
+!IF "$(CFG)" == "mod_log_forensic - Win32 Release"
+
+# PROP Ignore_Default_Tool 1
+# Begin Custom Build - Creating Version Resource
+InputPath=..\..\build\win32\win32ver.awk
+
+".\mod_log_forensic.rc" : $(SOURCE) "$(INTDIR)" "$(OUTDIR)"
+ awk -f ../../build/win32/win32ver.awk mod_log_forensic.so "log_forensic_module for Apache" ../../include/ap_release.h > .\mod_log_forensic.rc
+
+# End Custom Build
+
+!ELSEIF "$(CFG)" == "mod_log_forensic - Win32 Debug"
+
+# PROP Ignore_Default_Tool 1
+# Begin Custom Build - Creating Version Resource
+InputPath=..\..\build\win32\win32ver.awk
+
+".\mod_log_forensic.rc" : $(SOURCE) "$(INTDIR)" "$(OUTDIR)"
+ awk -f ../../build/win32/win32ver.awk mod_log_forensic.so "log_forensic_module for Apache" ../../include/ap_release.h > .\mod_log_forensic.rc
+
+# End Custom Build
+
+!ENDIF
+
+# End Source File
+# End Target
+# End Project
diff --git a/modules/loggers/mod_log_forensic.exp b/modules/loggers/mod_log_forensic.exp
new file mode 100644
index 00000000000..92f5075b4eb
--- /dev/null
+++ b/modules/loggers/mod_log_forensic.exp
@@ -0,0 +1 @@
+log_forensic_module