ゼロから始めるインターネットセキュリティ講座

３時間目は、ApacheをSSL対応にするためのパッケージであるApa che-SSLのインストールと、証明書リポジトリの構築を行ないます。ここまで来ればPKI環境構築はもうすぐですのでがんばりましょう。

はじめに

　連載の第１回目ではPKIの現状について簡単に説明しましたが、ここ数カ月の間に（特に日本国内で）PKI関連の大きな動きがいくつかありました。まず第１は、４月14日に電子署名・認証法案が国会に提出されたことです。電子署名・認証法案とは、国が認めた認証機関から証明書が発行されている鍵ペアによる電子署名に対して、これまで一般に使われてきた押印や署名と同じ効力を推定することを規定した法案で、通産／郵政／法務省によって提案されました。この法案がとおれば、電子的に証明された電子文書が法的に正しいことが保証されることになります。法案では、国の認可を受けた認証機関に対して虚偽の申請をして不正な証明書の発行を受けた場合には、３年以下の懲役刑または200万円以下の罰則を設けています。

また同じ日に、サイバートラストや日本ベリサインなど、全15社により電子証明書の仕様を統一についてのガイドラインが発表されました。第１回でもお話したとおり電子証明書はX.509と呼ばれる規格に基づいていますが、文字コードの扱いや証明書の利用ポリシーなどについては標準化が行なわれていません。今回の合意では、これらの点について各社が証明書の相互流通もにらんだ共通化を行なうための第一歩ということのようです。一方政府では、ミレニアムプロジェクトのかなめとして電子政府の実現に向けて政府認証機関（GPKI）の構築を進めています。PKIが日常生活であたりまえのように使われる日は意外と近いのかもしれません。

さて今回は、Apache-SSLとOpenLDAPのインストールについて解説します。動作環境は、前回と同じくSolaris 2.5.1を利用しています。

Apache-SSL

パッケージの入手

　Apache-SSLは、WWWサーバであるApa cheをSSL対応にするためのパッケージです。このパッケージには、ApacheからOpen SSLのライブラリを呼び出すためのモジュール群が含まれています。Apache-SSLのインストールには、以下の３つのパッケージが必要ですが、このうちOpenSSLは先月インストールしたものを用います。

• Apache 1.3.12
• Apache-SSL 1.39
• OpenSSL 0.9.4

% tar -zxvf apache_1.3.12.tar.gz
% cd apache_1.3.12
% tar -zxvf ../apache_1.3.12+ssl_1.39.tar.gz

FixPatchの実行

　次に、apache_1.3.12のソースツリーのトップにあるFixPatchを実行します。FixPatchを実行すると、ApacheのソースにSSLパッチを当てるか聞いてくるので“y”と入力するとパッチが当てられ（デフォルトはn）、openSSLのソースディレクトリが探索されます。もしFixPatchがopenSSLを見つけることができない場合には、

% FixPatch /usr/local/src/openssl-0.9.4

makeとインストール

　インストール前にconfigureとmakeを実行したあと、インストールを行ないます*1。

% ./configure
% make |& tee make.log
% su
# make install |& tee install.log

サーバ証明書の作成

　次にこのWWWサーバで使うサーバ証明書を作成します。サーバ証明書はApache-SSLのソースツリーのsrcディレクトリで

% make certificate

　できあがった証明書は、httpsd.pemという名前でSSLconf/confに作成されます。このhttpsd.pemとそのハッシュのシンボリックリンクは、次の項で説明するSSL CertificateFileで設定する場所にコピーしておきます。

httpsd.confの設定

　次に/usr/local/apache/conf/httpsd.confの設定を行ないます。httpsd.confはapacheのデフォルト設定がコピーされているだけなので、SSLに関する設定を追加します。SSLの設定サンプルは、apacheのソースツリーのSSLconf/conf/httpd.confにあるので、それをhttpsd.confにマージして必要な部分を変更すればOKです（リスト1）。各項目の説明に関しては、apache-SSLの日本語によるサイト（http://japache.infoscience.co.jp/ Apache-SSL/）やUNIX MAGAZINE１月号（アスキー）のUNIX Communication Notesが参考になりますが、ここでは設定の中で環境に応じて変更する必要のあるものについてのみ説明します。

リスト１●httpsd.confの設定例（SSLに関する部分のみ）

LogLevel debug
SSLNoCAList
ServerType standalone
DocumentRoot /usr/local/apacheSSL/htdocs


SSLRequireSSL


TransferLog logs/transfer_log

SSLEnable
SSLCacheServerPath bin/gcache
SSLCacheServerPort logs/gcache_port
SSLCacheServerRunDir /tmp
SSLSessionCacheTimeout 15
SSLCACertificatePath /usr/local/apacheSSL/conf
SSLCertificateFile /usr/local/apacheSSL/conf/httpsd.pem
#SSLCertificateKeyFile /some/place/with/your.key
SSLVerifyClient 3
SSLVerifyDepth 10
#SSLFakeBasicAuth
SSLBanCipher NULL-MD5:NULL-SHA
CustomLog       logs/ssl_log "%t %{version}c %{cipher}c %{clientcert}c"

SSLCACertificatePath

　クライアント認証をする際に、受け入れるクライアント証明書を発行する認証局の証明書を格納するディレクトリ。この項目の代わりにSSLCACertificateFileで証明書ファイルを指定することで、特定の認証局によって発行されたクライアント証明書のみを受け入れることも可能です。

SSLCertificateFile

　このサーバの証明書のファイル名。

SSLCertificateKeyFile

　このサーバの秘密鍵のファイル。SSL CertificateFileで示したファイルに秘密鍵が含まれている場合には、この指定は必要ありません。make certificateコマンドで証明書を作成した場合には、秘密鍵は証明書に含まれています。

SSLVerifyClient

　クライアントに対してどのような認証を要求するかを設定します。この項目は０〜３の数字となり、それぞれ以下のような認証を意味します。 ０：認証を必要としません。
１：クライアントは、証明書を提示して認証を受けることができます。ただし、この場合の証明書は、サーバに信頼されているCA（SSLCACertificatePathに証明書が格納されているCA）でなければなりません。
２：クライアントは、サーバに信頼されているCAによる証明書を提出しなければなりません。
３：クライアントは証明書を提示して認証を受けることができます。この場合の証明書は、サーバに信頼されているCAでなくても問題ありません。

SLFakeBasicAuth

　通常のパスワード認証のかわりに、証明書のクライアント識別子（DN：Distinguished Name）を用いた認証をないます。クライアント証明書によるアクセスコントロールを行なう場合にこれを指定します。

httpsdの起動

　設定が終わったらhttpsdを起動します。

# /usr/local/apache/bin/httpsdctl start

OpenLDAP

　ここでは、LDAPと呼ばれるディレクトリサーバを使って、第１回で説明した証明書リポジトリを構築します（図1）。ディレクトリサーバとは、さまざまな情報をUNIXやWindowsのファイルシステムと同じ、ディレクトリと呼ばれる階層型の構造で管理するシステムのことです。ディレクトリサーバは、証明書を管理するのにたいへん向いています。たとえば、ある認証局の証明書をディレクトリサーバに登録し、その認証局から発行した証明書を認証局のエントリの下に登録すれば、直観的に分かりやすい形で証明書が整理できます。また、社内でPKIを構築する際には、部や課といった階層組織をそのままディレクトリの形で表現することができます。

図1　証明書リポジトリ

　今回は、OpenLDAPと呼ばれるオープンソースのディレクトリサーバを使って証明書リポジトリを構築します。OpenLDAPも、ほかのオープンソースソフトウェアと同様、速いテンポでバージョンアップが進んでいます。今回は、執筆時の最新版である1.2. 10を使いました。

パッケージの入手とインストール

　OpenLDAPは“http://www.openldap.org/”から入手できます。まずは、入手したパッケージを適当なディレクトリに展開しmakeします*2。

% tar -zxfv openldap-1.2.10.tgz
% cd openldap-1.2.10
% ./configure
% make depend
% make |& tee make.log

% cd tests
% make |& tee make.log

% cd ..
% su
# make install |& tee install.log

slapdの起動

　インストールが終了したら、LDAPのサーバプログラムであるslapdを起動します。まず/usr/local/etc/openldap/slapd.confの設定を行ないます（リスト2）。suffixには証明書リポジトリの頂点（ルート）となるべきエントリを記述します。今回の例では、商店街の証明書リポジトリを想定しているので、suffixを

o=nikoniko shopping center, l=fujisawa, st=kanagawa, c=JP

cn=admin, o=nikoniko shopping center, l=fujisawa, st=kanagawa, c=JP

　rootpwは、rootdnと同じくエントリの変更の際に聞かれるパスワードです。また、directoryは登録されたエントリなどの情報が保存されるディレクトリを指し、デフォルトは/usr/tmpです。今回は/usr/local/ldapとしています。 　slapd.confの設定が終わったら、slapdを起動します。slapdは、/usr/local/libexecにインストールされています。

# /usr/local/libexec/slapd -f /usr/local/etc/openldap/slapd.conf

リスト2●slapd.confの設定例

include         /usr/local/etc/openldap/slapd.at.conf
include         /usr/local/etc/openldap/slapd.oc.conf
schemacheck     off

pidfile         /usr/local/var/slapd.pid
argsfile        /usr/local/var/slapd.args

#######################################################################
# ldbm database definitions
#######################################################################

database        ldbm
suffix          "o=nikoniko shopping center, l=fujisawa, st=kanagawa, c=jp"
rootdn          "cn=admin, o=nikoniko shopping center, l=fujisawa, st=kanagawa, c=jp"
rootpw          sEcrET
directory       /usr/local/ldap

証明書エントリの作成

　次に、ディレクトリに登録する証明書 エントリを作成します。証明書エントリはLDIF（Ldap Data Interexchange Format）と呼ばれる形式で作成します。LDIFで書かれたエントリの例をリスト3に示します。１つのファイルには空行をセパレータとして複数のエントリを記述することができます。各エントリの間に空行がなかったり、複数行の空行が入っていると、うまく登録できないので注意が必要です。

リスト3●LDIFファイルの例

dn: o=nikoniko shopping center, l=fujisawa, st=kanagawa, c=JP
cn: NSC CA
o: nikoniko shopping center
l: fujisawa
st: kanagawa
mail: ca@nsc.org
objectclass: organizatin
userCertificate;binary::　MIIDyjCCAzOgAwIBAgIBADANBgkqhkiG9w0B
（にこにこ商店街のCA証明書：以下省略）

dn: cn=hanamaru-bento, o=nikoniko shopping center, l=fujisawa, st=kanagawa, c=JP
cn: hanamaru-bento
o: nikoniko shopping center
l: fujisawa
st: kanagawa
mail: hanamaru@nsc.org
objectclass: organization
userCertificate;binary:: MIIEBjCCA2+gAwIBAgIBAzANBgkqhkiG9w0B
（はなまる弁当のサーバ証明書：以下省略）

　LDIFの各エントリは、

• １つの識別子（DN）
• １つ以上のオブジェクトクラス
• 任意の数の属性名と属性値のペア

　リスト3では２つのエントリを作成しています。１つ目はルートエントリである“o= nikoniko shopping center, l=fujisawa, st= kanagawa, c=JP”で、２つ目は商店街の「はなまる弁当」のエントリです。このエントリには、前回作成したはなまる弁当の公開鍵証明書が“userCertificate;binary”という属性名で登録されています。LDIFファイルの作成ができたら、ldapaddコマンドでエントリを登録します。

% ldapadd -D "cn=admin, o=nikoniko shopping center, l=fujisawa, st=kanagawa, c=JP" -W < entry.ldif

% ldapsearch -L -b "o=nikoniko shopping center, l=fujisawa, st=kanagawa, c=JP" "（objectclass=*）"

% ldapdelete -D "cn=admin, o=nikoniko shopping center, l=fujisawa, st=kanagawa, c=JP" -W "cn=hanamaru-bento, o=nikoniko shopping center, l=fujisawa, st=kanagawa, c=JP"

★

　次回は、今回インストールしたソフトウェアと、前回作成したサーバ／クライアント証明書を使って、いよいよ実際にPKIを用いたお弁当屋さんの注文サーバの構築と運用を行ないます。

＜＜用語解説＞＞

make |& tee make.log

　UNIX系OSにはリダイレクト（>）やパイプ（|）を組み合わせて、複数のコマンドを同時に利用することができる。通常の利用法であれば、結果が標準出力に出力されるものをリダイレクトしてファイルに出力するなどといった使い方をする。しかし、UNIXにはもう１つ「標準エラー出力」と呼ばれるものがある。これは通常のリダイレクトではファイルに保存することができない。これをファイルなどにリダイレクトするのに必要なのが“&”（アンパサンド）である。今回の例では“make >& make.log”でmake.logにログを記録することは可能だ。ただその場合、標準出力への出力は行なわれない。標準出力に出力させ、かつファイルへもログを記録したい場合があるだろう。その際のコマンドが“tee”である。teeは標準出力を複数出力するためのコマンドで、これをパイプと、先程の&を組み合わせて利用することにより、標準出力へ出力されるのと同時に、teeによりもう１つ出力されたログがmake.logに格納されることになる。

make depend

　dependを追加することにより、makeの対象となるファイルの依存関係をチェックする。ソースファイルがある別のファイルをincludeしている場合に、includeされているファイルが存在しているか、正しいファイルかどうかを調べる。