emacs インストール

実は、vi 使いなので、emacs の事には触れなかったのですが、vi のモードと日本語の相性が良くないのと、今後インストールする lisp などのために、emacs をインストールすることにしました。しかし普通に入れるのはつまらないので、coLinux のテキストベース環境用に、いらない機能をやめてコンパイルしてみます。

GNUからたどって、Emacs 21.4 をインストールしてみます。leim も SSK とか使えるので入れます。

$ gpg --verify emacs-21.4a.tar.gz.sig
gpg: 2005年02月17日 22時21分03秒 JSTにDSA鍵ID BE216115で施された署名
gpg: “Francesco Potorti <pot@potorti.it>”からの正しい署名
gpg:                 別名“Francesco Potorti <pot@gnu.org>”
gpg:                 別名“Francesco Potorti <Potorti@isti.cnr.it>”
gpg:                 別名“Francesco Potorti <pot@softwarelibero.it>”
gpg: 警告: この鍵は信用できる署名で証明されていません!
gpg:       この署名が所有者のものかどうかの検証手段がありません。
主鍵の指紋: 4B02 6187 5C03 D6B1 2E31  7666 09DF 2DC9 BE21 6115
$ gpg --verify leim-21.4.tar.gz.sig
gpg: 2005年02月17日 21時02分42秒 JSTにDSA鍵ID BE216115で施された署名
gpg: “Francesco Potorti <pot@potorti.it>”からの正しい署名
gpg:                 別名“Francesco Potorti <pot@gnu.org>”
gpg:                 別名“Francesco Potorti <Potorti@isti.cnr.it>”
gpg:                 別名“Francesco Potorti <pot@softwarelibero.it>”
gpg: 警告: この鍵は信用できる署名で証明されていません!
gpg:       この署名が所有者のものかどうかの検証手段がありません。
主鍵の指紋: 4B02 6187 5C03 D6B1 2E31  7666 09DF 2DC9 BE21 6115
$

$ tar xzf emacs-21.4a.tar.gz
$ tar xzf leim-21.4.tar.gz
$ cd emacs-21.4
$ ./configure --without-pop --without-toolkit-scroll-bars --without-xim 
...................
$ make 
...................
$
# make install
...................
#

結構簡単にできました。しかし、日本語表示が変です。全部 EUC　として、TeraTerm の設定で、漢字受信のコードをEUCとすると、JIS , SJIS , EUC のファイルは正確に表示され、utf-8 の場合だけ文字化けすることから、utf-8 周りの問題です。
http://linux.seindal.dk/item32.html を参考にすると、.emacs は、

(setq locale-coding-system 'utf-8)
(set-terminal-coding-system 'utf-8)
(set-keyboard-coding-system 'utf-8)
(set-selection-coding-system 'utf-8)
(prefer-coding-system 'utf-8)

です。が、文字が半角で認識されているような動きをします。そこで、Mule-UCS(http://www.meadowy.org/~shirai/) を追加します。

$ tar xzf mule-ucs.tar.gz
$ cd mule-ucs-20061127-1
# emacs -q --no-site-file -batch -l mucs-comp.el
..........
# cd lisp
# cp *.el *.elc /usr/local/share/emacs/site-lisp
#
# cd jisx0213
# emacs -q --no-site-file -batch -l x0213-comp.el
..........
# cp *.el *.elc /usr/local/share/emacs/site-lisp
#

$ vi ~/.emacs

(require 'un-define)
(require 'jisx0213)
(set-language-environment "Japanese")
(set-terminal-coding-system 'utf-8)
(set-keyboard-coding-system 'utf-8)
(setq default-buffer-file-coding-system 'utf-8)

$

この設定で、jis, sjis, euc, utf-8 の各ファイルの編集で、Windowsの仮名漢字変換による入力と、Ctrl-\による仮名漢字変換の両方ができることが分かりました。上の jisx0213 がないといろいろおかしくなります。最後の
default-buffer-file-coding-system を設定しないと、新しいファイルのコードは、jis になるようです。

画面最上部にある、

File Edit Options Buffers Tools Help

を消すには、

M-x menu-bar-mode RET

です。.emacs に書くには、

(menu-bar-mode -1)

みたいにすればよいと思います。

WebDAVで気になること

Apache httpd 2.2.4 で WebDAV を実行できるようになりましたが、WebDAV を利用してファイルを書き込みにいくと作成されたファイルのパーミッションは

# ls -l /home/data/davhome/dav/test001.txt
-rw-r--r-- 1 www www ...................
#

となって、同じグループに属する複数のユーザで利用するときに、coLinux 側から修正できません。

# umask
0022
#

だからだと思います。これは通常は変更しません。

しかし umask を変更する httpd のディレクティブはないみたいです。確か Apache httpd 1.3.37 あたりで mod_dav を持ってくるときにソースを見たら open()　が直接使ってあったので、その直前に umask(00002) とか行えばできそうです。httpd-2.2.4/modules/dav/ 以下を調べると open()がありません。おそらく Apache httpd の module に入ったときに変更があり、変わりに

apr_file_open()

が使われているようです。

http://dev.ariel-networks.com/apr/apr-tutorial/html/apr-tutorial-5.htmlによると、APR_OS_DEFAULT (0666 らしいです）が使えるらしいので、dav/fs 内を調べたところ、repos.c にそれらしき記述が。

/* ### do we need to deal with the umask? */
status = apr_file_open(&outf, dst, APR_WRITE | APR_CREATE | APR_TRUNCATE
                       | APR_BINARY, perms, p);

ここは、dav_fs_copymove_file() 内です。ここに

umask(00002);

と入れてみます。しかしこれははずれ。さらに dav_fs_open_stream() あたりにそれらしき記述があるので、この関数内の最初に umask(00002); を入れて、Windows XP からこのフォルダに何かファイルをコピーしたところ

# ls -l /home/data/davhome/dav/test001.txt
-rw-rw-r-- 1 www www ...................
#

これで一応うまくいきました。実際には、1回ここを通れば以降はすべてこの umask が有効になり、何回も umask を実行してしまうのであまり良い修正ではありませんし、他に影響を与えないように終わったら元に戻しておかないといけないと思いますので、すごくいい加減ですが実験なのでこれで OK です。

忘れないように書いておきますが、ソースを修正したら httpd-2.2.4/ で、

$ make
...........
# make install 
...........
# /etc/init.d/httpd stop
# /etc/init.d/httpd start
#

のようにしてから試します。その際、/usr/local/httpd224/conf 以下の設定は変更されず、/usr/local/httpd224/conf/original 以下が置き換わるだけです。便利ですね。

coLinux 側で、group 名 www のファイルを各ユーザが扱えるようにするには、

# lgroupmod -M espiya www

$ groups espiya
espiya: user www

$ newgrp www　

みたいなコマンドを使うわけです。フォルダ（coLinux 側ではディレクトリ) の場合も1回 umask を通ってしまえばこちらが有効になります。

こんな修正がお気楽にできるのも、家庭内の coLinux 環境で、Apache httpd をソースからインストールしたからで

Apache httpd 2.2.4でWebDAV + ssl + Digest

前回で OpenSSL の設定も終わりクライアント認証もできたので、WebDAV + ssl + Digest 認証を試してみます。

Apache httpd で ssl をクライアント認証にしておけば、クライアント証明書と自己認証型CA証明書を持っていないとアクセスできません。さらに WebDAV を使うときはDigest認証でパスワードを求められますから、一応安全といえるかもしれません。（本当は全部いっぺんに試してみたかっただけです。）

あらかじめ OpenSSL で証明書を用意して、それを httpd に反映しておきます。http の参照と https の参照は分離しておきます。ここでは、

http://www.example.co.jp/  なら、  /home/data/www     を
https://www.example.co.jp/ なら、　/home/data/davhome を

ドキュメントルートにします。

すでに、httpd は WebDAV に対応するようにコンパイルしてあります。
クライアント認証の設定も済んでいます。httpd 2.2.4 の設定ファイル httpd.conf,httpd-ssl.conf,httpd-dav.conf を修正します。気になる点だけ示すと、

・/usr/local/httpd224/conf/httpd.conf

User www
Group www

Include conf/extra/httpd-dav.conf
Include conf/extra/httpd-ssl.conf

・/usr/local/httpd224/conf/extra/httpd-ssl.conf

DocumentRoot "/home/data/davhome"
ServerName www.example.co.jp:443
ServerAdmin root@example.co.jp

SSLEngine on

SSLCertificateFile /usr/local/keys/server/server.crt
SSLCertificateKeyFile /usr/local/keys/server/servernp.key

SSLCACertificatePath /usr/local/keys/CA/
SSLCACertificateFile /usr/local/keys/CA/cacert.crt

SSLVerifyClient require
SSLVerifyDepth  10

<Directory "/home/data/davhome">
    Options None
    AllowOverride None
    Order allow,deny
    Allow from 192.168.1
</Directory>   

・/usr/local/httpd224/conf/httpd-dav.conf

DavLockDB "/usr/local/var/dav/DavLock"
Alias /dev "/home/data/davhome/dav"

<Directory "/home/data/davhome/dav">
    Dav On
    Order Allow,Deny
    Allow from 192.168.1
    AuthType Digest
    AuthName DAV-upload
    AuthUserFile "/usr/local/etc/password/davuser1.passwd"
    <LimitExcept GET OPTIONS>
        require user espiya
    </LimitExcept>
</Directory>

ここの LimitExcept は、このディレクトリを Web で公開するためです。ファイルのやり取りだけに使いたい場合はこれなしで直接 require を普通に指定すれば良いです。必要なディレクトリやパスワードファイルを準備します。

# mkdir /usr/local/etc/password
# mkdir /usr/local/var/dav
# chown www.www /usr/local/var/dav
# mkdir /home/data/davhome
# mkdir /home/data/davhome/dav
# chmod 0775 /home/data/davhome/dav
# chown www.www /home/data/davhome/dav
    
# htdigest -c '/usr/local/etc/password/davuser1.passwd' DAV-upload espiya
..............   Digest 認証のパスワード作成
# /etc/init.d/httpd restart

Windows XP で試してみます。「マイネットワーク」→「ネットワークプレースを追加する」→「ネットワークプレースの追加ウィザード」ウィンドウ　→「次へ」→「別のネットワークの場所を選択」→「次へ」
ここで、アドレス https://www.example.co.jp/dav/ を指定し、
「デジタル証明書の選択」でクライアント証明書を選択する　→「ネットワークのパスワードを入力」ウィンドウ→ユーザー名、パスワードで htdigest で指定したものを入れるとアイコンが作成され、開くと指定したディレクトリが Windows のフォルダとして開けました。

ここで、/home/data/davhome の下に dav ディレクトリを作ったのは、Digest パスワードファイルを利用者ごとに作成して、利用するディレクトリも分けようとの意図からです。つまり、/home/data/davhome/dav が参照できるのは、/usr/local/etc/password/davuser1.passwd にユーザ登録されている利用者だけです。

ところで、ssl を利用しない場合に「ネットワークプレースに追加」しようとして、ユーザとパスワードを入力してもうまく動作しません。その場合は、アドレスの最後に ? 文字を付けるそうです。Windows XP のWebDAV実装がそうなっているらしいです。? を入れるとユーザとパスワードを入力するウィンドウの形も明らかに変わっており確かにおかしいです。このことが報告されていた

(http://mtlab.ecn.fpu.ac.jp/WSM_2004/040601170336.html)
でご指摘のとおり、
Digest: user`サーバ名ユーザ名' in realm `realm名' not found /dav　
のようなログがでます。

ということは、Windows XP では、https の時（もしかしたらクライアント認証だけ？）だけ「?」文字が要らないようです。これはびっくりです。いったいいかなる仕様でしょうか。

次回もう少し、WebDAV について試してみます。

OpenSSLについて その５

長い間 coLinux で OpenSSL 0.9.8a をいろいろ試してきましたが、ついでにクライアント認証もしてみます。SSL:クライアント認証が参考になります。これも、openssl.cnf を修正する必要がありそうです。この場合は、

basicConstraints = CA:FALSE
nsCertType = client, email

らしいです。
この client は、クライアント認証のように自分（この証明書を持っていて相手に送りつける）はクライアントであるという意味みたいですね。それでサーバ用の証明書は自分はサーバであるから server で、自己認証型の証明書は自分は認証局なので sslCA ということみたいです。本当かどうかはともかく一応納得しました。
httpd のバージョンアップを考えて、ここではキーの置く場所は独立していたほうが良いので、

# mkdir /usr/local/keys
# mkdir /usr/local/keys/CA
# mkdir /usr/local/keys/server
# mkdir /usr/local/keys/key1

としてCA、サーバ関係、クライアント用は独立して入れるようにします。書いてありませんが、コピーが終わったらキー関係はすべて消しました。

# cd /usr/local/httpd224/conf
# mv server.crt /usr/local/keys/server/server.crt
# mv server.key /usr/local/keys/server/servernp.key
# cp /usr/local/CA/cacert.pem  /usr/local/keys/CA/cacert.crt
#

準備ができたので早速クライアント用の秘密鍵とCAで署名した証明書を作ります。
まず、openssl.cnf の[ usr_cert ] セクションを修正します。

basicConstraints=CA:FALSE
nsCertType = client, email
# keyUsage = nonRepudiation, digitalSignature, keyEncipherment

最後の keyUsage は、最初からこのようにコメントになっているものですが、問題になってからはずすことにします。ここでは参考までに書いてあるだけです。秘密鍵と証明書の作成する openssl req と openssl ca は、CA.sh -newreq と CA.sh -sign と同じものですからこれを利用します。

# cd /usr/local/keys/key1
# /etc/pki/tls/misc/CA.sh -newreq
........... 　秘密鍵のパスフレーズを設定
# /etc/pki/tls/misc/CA.sh -sign
...........   CAのパスフレーズを入力

これで、秘密鍵 newkey.pem と 証明書 newcert.pem が作成されました。newreq.pem はCSRなので消しても良いです。

クライアント用証明書は、Windows では PKCS#12 形式にする必要があるそうなので変換します。

# openssl pkcs12 -export -clcerts -inkey newkey.pem -in newcert.pem -out newclient.p12
................  秘密鍵のパスフレーズを入力
................  クライアント用証明書のパスワードを設定
#

設定する人には、newclient.p12 を渡してクライアント用証明書のパスフレーズを教えます。

後は Windows 上でインポートすればここで生成した秘密鍵などはサーバ側では必要ないみたいなので、ほかに見えないように、ディレクトリ key1 を 0700 にしておきます。

Apache httpd 2.2.4 用の設定の修正は、/usr/local/httpd224/conf/extra/httpd-ssl.conf 内で、

SSLCertificateFile /usr/local/keys/server/server.crt
SSLCertificateKeyFile /usr/local/keys/server/servernp.key
SSLCACertificatePath /usr/local/keys/CA/
SSLCACertificateFile /usr/local/keys/CA/cacert.crt
SSLVerifyClient require
SSLVerifyDepth 10

のようにしました。最後の10は最初からコメントに書いてあったとおりです。

これで最初に証明書がない場合を試したところ、Internet Explorer では、「デジタル証明書の選択」ウィンドウが表示されてページが開けませんでした。

先ほどの newclient.p12 は、Windows では、Personal Information Exchange として表示されます。このファイルを右クリックすると「PFXのインストール」メニューがでますのでこれをクリックします。途中 newclient.p12 作成したパスワードを聞かれます。もう一度ブラウザで見ると、「デジタル証明書の選択」ウィンドウの名前と発行者に証明書が現れて「OK」をクリックするとページが参照できました。そのとき、鍵アイコンをクリックして表示される証明書は、SSLCertificateFile で指定した証明書でした。他の人がこのPC を使っても見えないようにする場合は、毎回パスフレーズを入力するようにもできます。

FireFox では newclient.p12 をインポートしていなければ、-12227 エラーになりました。そこで、newclient.p12 を「証明書マネージャ」→「あなたの証明書」でインポートしました。そのときパスワードを聞いてきます。２つ聞いてきますが適当に入力したので覚えていません。

ここでわざと登録してある「認証局証明書」を削除すると newclient.p12 の「用途」が不明になり、原因不明の問題により、.... のが表示されますが、「認証局証明書」がインポートしてあると「用途」がクライアントになり「SSLクライアント証明書」として認識されました。

また証明書の失効は、
証明書の失効とCRLの発行http://www.daily-labo.com/ygg16_4.htmlを参考にすればよさそうです。早速ためしてみます。

# echo '00' >/usr/local/CA/crlnumber　( crlnumber ファイルがないときだけ作成する。 )
# cd /usr/local/keys/key1
# openssl ca -gencrl -revoke newcert.pem
.............. CA のパスフレーズを入力
# cd /usr/local/CA
# openssl ca -gencrl -out key1-crl.pem
.............. CA のパスフレーズを入力
# mkdir /usr/local/keys/crl
# cp key1-crl.pem /usr/local/keys/crl/key1-crl.pem

Apache httpd に　CRLを指定するため、/usr/local/httpd224/conf/extra/httpd-ssl.conf の修正をします。

SSLCARevocationFile /usr/local/keys/crl/key1-crl.pem

これで、newclient.p12 をインポートしたブラウザでもアクセスできなくなります。もちろん新しいクライアント証明書があれば再び見られるようなりました。

おまけで、SSLCARevocationPath を指定する場合は、ハッシュ値のファイル名が必要らしいです。その場合は以下のようにするそうです。

ln -s cacert.crt `openssl x509 -noout -hash < cacert.crt`.0

しかし、これを試してもうまくいかなかったので、ご利用の際は必ず確認してください。

今回で OpenSSL については一応完了です。

OpenSSLについて その４

前回わかったことから、openssl ca コマンド実行時に　/etc/pki/tls/openssl.cnf をいちいち修正することにしました。

CA証明書を作るときは、[ usr_cert ] セクションに

basicConstraints = CA:true
nsCertType = sslCA, emailCA
keyUsage = cRLSign, keyCertSign

サーバ証明書を作るときは、[ usr_cert ] セクションに

basicConstraints = CA:FALSE
nsCertType = server,client,email

を指定してみました。keyUsage を指定したのは、公式な CA の証明書 RSA Security Inc - RSA Security 1024 v3 などからの類推です。作成したCA証明書 cacert.der を FireFox にインポートしてみると、インポート時の「証明書を表示」では、

「原因不明の問題により、この証明書の有効性を検証できませんでした。」

と表示されてしまいますが、無視して「OK」でインポートしてしまってから、「証明書マネージャ」ウィンドウの「認証局証明」で、fedora.example.co.jp を選択して、「表示」で「証明書ビューア」ウィンドウが開いたら、「一般」で、

この証明書は以下の用途に使用する証明書であると検証されました。
SSL認証局

のように表示されて、うまく?いきました。FireFox で該当ページを見て、サーバの証明書を「証明書ビューア」で確認すると、

この証明書は以下の用途に使用する証明書であると検証されました。
SSL　クライアント証明書
SSL　サーバ証明書

「詳細」で見ると、Certificate Basic Constraints は、

Not Critical
Is not a Certificate Authority

と表示されます。つまり、FireFox 2.0.0.1 においては、

CA証明書の場合は、basicConstraints = CA:true と指定すれば、
「この証明書は以下の用途に使用する証明書であると検証されました。」となり、
nsCertType = sslCA ？が、「SSL　認証局」と認識され、

サーバの証明書の場合は、basicConstraints = CA:FALSE でも同じく「検証され」、
nsCertType = client, server ？なら、「SSL　クライアント証明書」「SSL　サーバ証明書」と認識

されるようです。ちなみに、現時点の Yahoo のログイン画面のものを参考にすると、

Certificate Basic Constraints
     Not Critical
     Is not a Certificate Authority
Certificate Key Usage
     Not Critical
     Signing
     Key Encipheriment
SSL サーバ証明書

ですから、ちょっとあいまいですが、

basicConstraints = CA:FALSE
nsCertType : なし
keyUsage = codeSigning(?), KeyEncipherment

でしょうか。まねすると nsCertType = server でよさそうです。

以上まとめると、OpenSSL 0.9.8 以降の自己署名型のCAを使って Apache httpd 2.2.4 で ssl を利用するためには、

・openssl.cnf を以下のように修正します。openssl用作業ディレクトリです。
　　dir = /usr/local/CA 

・CA.sh を以下のように修正します。これで今いるディレクトリに証明書等が生成されます。
    CATOP=.

・自己署名型のCAの証明書を作ります。
　　まず openssl.cnf の [ usr_cert ] セクションで、次の指定を有効にします。
      basicConstraints=CA:true
      nsCertType = sslCA, emailCA
      keyUsage = cRLSign, KeyCertSign

　　cd /usr/local/CA 
    CA.sh -newca

・サーバ証明書のためのCSRを作ります。
　　まず openssl.cnf の [ usr_cert ] セクションで、次の指定を有効にします。    
      basicConstraints = CA:FALSE
      nsCertType = server

　　CA.sh -newreq

・サーバのCSRをCAで署名して証明書を作ります。
    CA.sh -sign

・サーバの秘密鍵のパスフレーズを解除します。
　　openssl rsa -in newkey.pem -out nopass.key

・サーバの証明書とサーバの鍵を Apache httpd の指定する場所に置きます。
　　サーバの証明書 newcert.pem , サーバの鍵 nopass.key です。
    cp  newcert.pem /usr/local/httpd/conf/server.crt
    cp  nopass.key /usr/local/httpd/conf/server.key

・すべての鍵は、chmod 0600 .. で、他人に見えないようにします。

・CA の証明書を der フォーマットに変換します。
    cd /usr/local/CA
    openssl x509 -in cacert.pem -outform DER -out cacert.der

・関係者に、cacert.der を配布して、各ブラウザにインポートします。

という感じでしょうか。CA.sh と openssl の対応付けは、以前にご紹介したとおりです。将来サーバ証明書でうまくいかなかったら、openssl.cnf で keyUsage を指定してみることにします。

keyUsage は、digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment, keyAgreement,
keyCertSign, cRLSign, encipherOnly, decipherOnly, serverAuth, clientAuth,
codeSigning, emailProtection, timeStamping, msCodeInd, msCodeCom, msCTLSign,
msSGC, msEFS, nsSGC

が指定できるらしいですが、いま分かっている対応関係は以下のとおりです。

cRLSign == CRL Signer
KeyCertSign == Certificate Signer

別に今までの作業をすべて coLinux で行ったからではないのですが、とても疲れました。次回にクライアン認証を試して、とりあえず OpenSSL は終わりにしたいです。

OpenSSLについて その３

引き続き OpenSSL 0.9.8a について見てみます。

公式の CA に署名を依頼する場合は、秘密鍵と CSR を作るわけですが、その CA の指示にしたがって作成するべきです。例えば、以下のような方法が一般的です。

openssl genrsa -des3 -out private.key 1024
openssl req -new -key private.key -out private.csr

つまり、openssl genrsa で秘密鍵を作り、それから openssl req で CSR を作ります。有効期限は、CA で署名する時に指定するはずです。これで認証会社から署名された証明書 *.crt が送られてきます。coLinux ではこれを利用する人はまずいないと思いますが。

さて、前回作成された証明書はこのままですとブラウザで表示するときに警告がでます。そこで、特定少数の人が ssl を利用してアクセスする場合を想定すると、あらかじめ上で作成した CA証明書 の cacert.pem を配布することになります。 Windows 上では、署名された証明書のファイル名 cacert.pem を cacert.crt とすれば、「セキュリティ証明書」として認識されますが、der 形式?に変換して配布するのが良いみたいです。der 形式に変換するには、

# cd /usr/local/CA
# openssl x509 -in cacert.pem -outform DER -out cacert.der

これを、Windows に持っていって開けば「証明書」ウィンドが表示されます。ここで、「証明書をインストール」をクリックすれば、Internet Explorer 用に証明書をインストールできます。

FireFox にインストールするには、「ツール」→「オプション」→「詳細」
→「証明書を表示」　→　「認証局証明書」　→「インポート」　→　ファイル cacert.der を選択すると、「証明書のインポート」ウィンドが表示されます。

「この認証局によるWebサイトの識別を信頼する」をクリックしてから「OK」をクリックすると、「証明書マネージャ」ウィンドウで証明書名と発行者名に
Example Ltd
fedora.example.co.jp
のように表示されます。

ところが、一見うまくいったみたいですがこれがうまくいきません。

どうやら、正しい認証局証明書の認識ができないようです。そこで、FireFox の「証明書ビューア」を使って調べてみました。「証明書ビューア」の「詳細」に問題ない公式の CAの証明書の１つは、

Netscape Certificate Type が　Not Critical SSL 認証局　Email Certificate Authority オブジェクトへの署名者

になっています。これが、(nsCertType : openssl.cnf 内の名前) に関連するもののようです。
また、Certificate Key Usage が (KeyUsage) に対応するようです。
証明書の中には、nsCertType または、KeyUsage のどちらかまたは両方が入っているようです。
また、Certificate Basic Constrains が (basicConstraints) に対応しており、

basicConstrains = critical,CA:true

と指定すると、Certificate Basic Constrains のフィールドの値が、

Critical
Is a Certificate Authority
Maximum number of intermediate CAs: unlimited

となるらようです。最後の行を変えるには、CA:TRUE, pathlen:0 のように pathlen を付ければいいみたいです。ここで、Is a Certificate Authority となっているのが重要らしいです。

Windows の「証明書」ウィンドウではどう表示されるかというと、「詳細」で「基本制限」フィールドの値が、

Subject Type=CA  Path Length Constraint=None 

と表示されるようです。CA:FALSE なら、

Subject Type=End Entity  Path Length Constraint=None 

みたいです。前回作った証明書では、CA:FALSE が指定されているのが今回の問題点の理由らしいことが分かりました。 そこで、公式な CA と同じ形式になるように、ためしに CA の証明書を作るときに、CA:ture となっている v3_ca セクションを使うように、-extensions v3_ca オプションを指定したら、ブラウザで参照時にエラーになってしまいました。

ということは、自己署名型の CA を作るときと、通常のサーバ用の証明書を作るときに openssl.cnf は直して使う必要があるようです。

続きは次回にしたいと思います。

OpenSSLについて その２

前回の続きで、OpenSSL 0.9.8a の設定をします。

結局、openssl.cnf は、以下の行を修正しました。*_default の変更はこれからのテストを簡単にするためです。

dir                             =  /usr/local/CA
countryName_default             = JP
stateOrProvinceName_default     = Tokyo
localityName_default            = 23-ku
0.organizationName_default      = Example Ltd
organizationalUnitName_default  = Espiya

openssl コマンドと CA.sh と混在して説明されている場合が多いですが、後でわけが分からなくなるので、CA.sh を使っているつもりで、直接 openssl コマンドを実行することにしました。以下のように CA.sh のコメントの順番で実行します。

   CA -newca ... will setup the right stuff
   CA -newreq ... will generate a certificate request
   CA -sign ... will sign the generated request and output

まず、CA.sh -newca に該当する部分を実行して、CAの秘密鍵と自己認証した証明書を作ります。

# mkdir /usr/local/CA
# chmod 0700 /usr/local/CA
# cd /usr/local/CA
# mkdir certs crl newcerts private
# chmod 0700 private
# echo "00" >serial
# touch index.txt

# openssl req -new -keyout ./private/cakey.pem -out ./careq.pem
..............  CA のパスフレーズを入れる。
# openssl ca -out ./cacert.pem -days 1095 -batch \ 
         -keyfile ./private/cakey.pem \
         -selfsign -infiles ./careq.pem
..............　先ほどの CA のパスフレーズを入れる。
#

これで、CAの秘密鍵 private/cakey.pem と これによって署名されたCAの自己署名型の証明書 cacert.pem が作成されました。

次に、CA.sh -newreq 部分を実行して、httpd サーバ用の秘密鍵とCSRを作成します。

# openssl req -new -keyout newkey.pem -out newreq.pem -days 365
...........    httpd サーバ用キーのパスフレーズを作成します。
#

httpd サーバ用の秘密鍵 newkey.pem と CSR newreq.pem が作成されました。CA 作成時の openssl req コマンドと有効期限の設定以外まったく同じになっています。

最後に、CA.sh -sign 部分を実行して、CAで署名します。

# openssl ca -policy policy_anything -out newcert.pem -infiles newreq.pem
..........  CAのパスフレーズを指定します。
#

CSR newreq.pem を読み込んで、CAで署名した証明書 newcert.pem が作成できました。-policy オプションを指定することが特徴です。
httpd をパスフレーズなしで起動できるようにパスフレーズを解除します。

# openssl rsa -in newkey.pem -out nopass.key
.......... httpd サーバ用のパスフレーズを入力します。 
# chmod 0600 nopass.key newkey.pem

apache httpd の ssl の設定どおりの場所に証明書とキーをコピーします。

# cp -p newcert.pem /usr/local/httpd224/conf/server.crt
# cp -p nopass.key /usr/local/httpd224/conf/server.key

apache httpd の設定を変更します。/usr/local/httpd224/conf/extra/httpd-ssl.conf の次の行を修正します。

DocumentRoot "/home/data/www"
ServerName www.example.co.jp:443
ServerAdmin root@example.co.jp

/usr/local/httpd224/conf/httpd.conf の次の行のコメントをはずします。

Include conf/extra/httpd-ssl.conf

httpd を再起動します。 昔あった、startssl はもう使えませんので普通の start で良いです。

# /etc/init.d/httpd stop
# /etc/init.d/httpd start

(ですが、いままで述べた手順では重大な落とし穴がありました。それは後ほど。）

忘れたときのためにまとめると、

ssl は、秘密鍵を作ると同時に CSR を作成し、その CSR を使って CA で署名した証明書を作り、秘密鍵と署名した証明書をペアで使う。

と、覚えればいいみたいです。これで一応すっきりしました。
しかし、ブラウザが違うと、nsCertType が影響するかもしれない不安は残ります。将来バージョンが上がるとまたおかしくなる可能性もあり、その場合はもう一度 CA.sh を見ることにします。

重大な落とし穴については次回にします。

OpenSSLについて その１

久しぶりの投稿です。現在の coLinux の運用状況ですが、

# uptime
 21:21:40 up 20 days, 23:42,  2 users,  load average: 0.00, 0.00, 0.00

20日も動いています。
さて、OpenSSL を試して、apache httpd 2.2.4 の sslサポートを有効にしてみます。coLinux サイトにある Fedora Core 5 では、OpenSSL は最初から含まれています。しかし、CA 構築のシェルスクリプト CA.sh や、OpenSSL の設定ファイルはいったいどこにあるのでしょうか。rpm で探してみます。

# rpm -qa |grep openssl
openssl-0.9.8a-5.4
openssl-devel-0.9.8a-5.4
# rpm -ql openssl-0.9.8a-5.4
/etc/pki/CA
...................
# openssl version
OpenSSL 0.9.8a 11 Oct 2005
#

ということは、OpenSSL のバージョンは 0.9.8a で、CA を作るためのシェルスクリプトは、

/etc/pki/tls/misc/CA

で、openssl の設定ファイルは、

/etc/pki/tls/openssl.cnf

です。早速 mod_ssl 用のキーを作成するのですが、これまた忘れやすいのでまとめておきます。ここでは、自分でCAになることにします。参考にしたものは、
OpenSSLによるCAの運営方法
OpenSSLでの自己認証局(CA)と自己証明書の作成
CAのためのOpenSSLの設定
あたりです。そのほか書ききれないくらい多いですが、OpenSSL のバージョンが影響しますので、自分のバージョンと記述の作成年月日を確認した方が良いと思います。

ところで、自分でCAになる方法が微妙に異なっていることが分かりましたので CA.sh スクリプトを見てみます。まず古い OpenSSL のソースの apps/CA.sh を調べてみたところ、0.9.7 から 0.9.8 になったところで、apps/CA.sh の -newca が変更になっていることが分かりました。CA.sh の -newca) のところを見てみますと、0.9.7e では、

$REQ -new -x509 -keyout ${CATOP}/private/$CAKEY \
     -out ${CATOP}/$CACERT $DAYS

とプライベートキーと一緒に自己証明書も生成するとこになっているのが、0.9.8a では、

$REQ -new -keyout ${CATOP}/private/$CAKEY \
                -out ${CATOP}/$CAREQ
$CA -out ${CATOP}/$CACERT $CADAYS -batch \
                -keyfile ${CATOP}/private/$CAKEY -selfsign \
                -infiles ${CATOP}/$CAREQ

となって、一度プライベートキーと CSR($CAREQ) を生成してから、改めて 0.9.8 から追加された、-selfsign オプションを付けて、-keyfile で指定したキーで署名（つまり自己署名）しているようです。

次に、openssl.cnf の中身を見てみます。これは、

[ セクション名 ]

という行でセクション名を定義して、その下の次のセクション名の行までが有効になるような仕組みです。更にセクションの中で = によって、別のセクションを指定できるようになっているようです。なんとなく sendmail.cf に似ています。

openssl ca の -extensions section オプションを見ると、デフォルトは x509_extensions セクションになるようです。openssl.cnf を探すと、CA_default セクションのところで、

x509_extensions = usr_cert

となっていますから、usr_cert セクションの指定になるわけです。

そこで分からないのは、openssl.cnf の usr_cert セクションや、v3_ca セクション( openssl req の場合に指定される) の中でコメントになっている nsCertType です。どうもNetscape 用で8ビットのビットフラグになっているらしく、順番に、
client, server, email, objsign, reserved, sslCA, emailCA, objCA
を意味するようですが、定義がよく分からないです。server を指定するとか、sslCA,emailCA を指定するとか入り乱れていますが、とりあえずコメントのままにします。

続きは次回にしたいと思います。