投稿者: kenti

本当は…ベリサインとか、その手の認証局に提出して認証鍵に承認してもらうものですが、実験として自分で認証をすることにします。暗号化目的だけであれば、これはこれでいいのかもしれません(^^；

[ 秘密鍵の作成 ] > openssl genrsa -des3 -rand /var/log/messages -out www.kenti.jp.pem 1024 23168 semi-random bytes loaded Generating RSA private key, 1024 bit long modulus …….++++++ ……….++++++ e is 65537 (0x10001) Enter PEM pass phrase: (パスフレーズを入力します) Verifying password – Enter PEM pass phrase: (同じものをもういちど)

こうして、www.kenti.jp.pem という秘密鍵ファイルが出来ます。間違ってもweb領域に置かないように…。

それと、パスフレーズを忘れないようにしましょう。忘れると、以下の公開鍵などができませんです。。。

[ 認証局への認証鍵作成 ] > openssl req -new -key www.kenti.jp.pem -out www.kenti.jp.csr Using configuration from /etc/ssl/openssl.cnf Enter PEM pass phrase: (秘密鍵を作成したパスフレーズを入力) You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter ‘.’, the field will be left blank. —– Country Name (2 letter code) [AU]:JP State or Province Name (full name) [Some-State]:Fukushima Locality Name (eg, city) []:Koriyama Organization Name (eg, company) [Internet Widgits Pty Ltd]:kenti Organizational Unit Name (eg, section) []: Common Name (eg, YOUR name) []:www.kenti.jp Email Address []:info@kenti.jp Please enter the following ‘extra’ attributes to be sent with your certificate request A challenge password []: An optional company name []:

ここで、www.kenti.jp.csr というファイルができあがります。本来はこのファイルを認証局へ送って、費用を払えばいいらしいです。(^^ゞ

でも今回は、自分で認証してしまいます。

[ 自分が認証局のつもりで認証をし、公開鍵の作成 ] > openssl x509 -req -days 365 -in www.kenti.jp.csr -signkey www.kenti.jp.pem -out www.kenti.jp.crt Signature ok subject=/C=JP/ST=Fukushima/L=Koriyama/O=kenti/CN=www.kenti.jp/Email=info@kenti.jp Getting Private key Enter PEM pass phrase: (秘密鍵のパスフレーズを入力)

これで、自分が認証・署名した公開鍵、www.kenti.jp.crt ができあがります。

ここまでできあがれば大丈夫でしょう。

あとは、秘密鍵の中に、パスフレーズを埋め込んでおくと、SSLページを表示させるときにパスフレーズを入力する必要がなくなりますので、やっておくといいのかな…。

（我が家はこの方法じゃないと、SSLページをうまく表示してくれませんでした。）

[ 秘密鍵にパスフレーズを埋め込む ] > mv www.kenti.jp.pem www.kenti.jp.pem.buckup (念のためバックアップ) > openssl rsa -in www.kenti.jp.pem.buckup -out www.kenti.jp.pem read RSA key Enter PEM pass phrase: (秘密鍵のパスフレーズを入力) writing RSA key

こうして、www.kenti.jp.pem という秘密鍵ファイルに、パスフレーズが埋め込まれました。

次に、ApacheのSSL設定を行います。設定は、ssl.confに書きます。

基本的には、デフォルトの設定のままで大丈夫ですが、当サイトの設定は以下の通りです。

（webからのパスワード変更、メールの転送設定のページなどに使っています。）

[ /usr/local/apache2/conf/ssl.conf ] ※白地部分が書き換えた場所です <IfDefine SSL> Listen 443 AddType application/x-x509-ca-cert .crt AddType application/x-pkcs7-crl .crl SSLSessionCache dbm:logs/ssl_scache SSLSessionCacheTimeout 300 SSLMutex file:logs/ssl_mutex SSLRandomSeed startup builtin SSLRandomSeed connect builtin <VirtualHost 61.206.126.90:443> ServerName www.kenti.jp:443 ServerAdmin info@kenti.jp DocumentRoot “/home/www/sslpage_html” ScriptAlias /cgi-bin/ /home/www/sslpage_html/cgi-bin/ SSLEngine on SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL (公開鍵の場所を指定します) SSLCertificateFile /usr/local/www/www.kenti.jp.crt (秘密鍵の場所を指定します) SSLCertificateKeyFile /usr/local/www/www.kenti.jp.pem SetEnvIf User-Agent “.*MSIE.*” ¥ nokeepalive ssl-unclean-shutdown ¥ downgrade-1.0 force-response-1.0 </VirtualHost> </IfDefine>

我が家はIPベースで動かす方法をとったので、通常のwebページにもVirtualの設定を行いました。

こうすることで、普通のwebページと、SSLページを同居させることが出来ます。

[ /usr/local/apache2/conf/httpd.conf ] ※一番最後に追加 NameVirtualHost 61.206.126.90:80 <VirtualHost 61.206.126.90:80> ServerName www.kenti.jp DocumentRoot /home/www/html </VirtualHost>

あとは、ApacheをSSL機能付きで、以下のように起動させます。

気をつけることは、通常の起動方法とは少しだけ変わります。

# /usr/local/apache2/bin/apachectl stop (既に動作していたら、止めます) # /usr/local/apache2/bin/apachectl sslstart (SSL機能付きでスタート)

普通に、start ではないことに注意して下さい。

無事起動したか、アクセスして確認してみて下さい。

[ 通常のwebページ ] http://www.kenti.jp

[ SSLのページ ] https://www.kenti.jp/

(自己認証のため、警告が出ますがそのまま進むとSSLページに行きます)

HDDはそのまま引っこ抜いてなんとか動くだろう…ぐらいの甘い考えだったのですが、以下のような問題にぶち当たりました。

[/boot/loader.conf] hw.ata.ata_dma=”0″ ;HDDのDMA転送を無効にする。

…よくやるのです。。。これ。（上記を一時的に指示するには、起動する前に set hw.ata.ata_dma=0 をして boot でも可能です。）
ちなみに、FreeBSD4系の時は、起動時にHDDのDMA転送がうまくいかないとき、３回ほどDMA転送ができるか試した後に、PIO4とか切り変わるのですが、FreeBSD5系からは自分で明示的に指示しないとだめなようです。

なんだろうなぁ…。
あとは、ネットワークアダプタも若干変更があったため、インターフェースにあわせて書き換えます。

[/etc/rc.conf] #ifconfig_fxp0=”inet 192.168.1.1 netmask 255.255.255.0″ ifconfig_xl0=”inet 192.168.1.1 netmask 255.255.255.0″

Linuxと違って、１つのファイルにこうやって書けるのはありがたいなぁ、と思う今日この頃です。

で、今回なんでサーバを入れ替えたかといいますと、『MovableTypeでエントリーを投稿したとき、再構築がもうちょっと早くならないん？』というのがきっかけでして、ここに至る次第でございます。

しかし、入れ替えましたものの…気持ちホンワカ少しだけ早く…なったような気がします。。。

コマンド : chflags

フラグの設定	フラグの解除	フラグの内容	必要な権限
arch	noarch	archived	root
opaque	noopaque	opaque	所有者またはroot
nodump	nonodump	nodump	所有者またはroot
sappnd	nosappnd	system append-only	root
schg	noschg	system immutable	root
sunlnk	nosunlnk	system undeletable	root
uappnd	nouappnd	user append-only	所有者またはroot
uchg	nouchg	user immutable	所有者またはroot
uunlnk	nouunlnk	user undeletable	所有者またはroot

なんだかはよくわかりませんが、immutableは変更不可、undeletableは削除不可なのだそうです。

ということは…。

# chflags schg /libexec
# chflags schg /libexec/ld-elf.so.1
#
#
# mv ld-elf.so.1 ld-elf.so.1.1
mv: rename ld-elf.so.1 to ld-elf.so.1.1: Operation not permitted
#

とりあえず移動やリネームによるアキレス腱は消えました。
そして、肝心の削除ですが、

# rm ld-elf.so.1
override r-xr-xr-x root/wheel schg for ld-elf.so.1? y
rm: ld-elf.so.1: Operation not permitted

消せなくなりました。よかったー。(^^；

そのときはとりあえずしのぎで、/usr/libexec/ld-elf.so.1 を /libexec/ld-elf.so.1 にコピーして終了。
その後なんとなく気持ち悪いので、以下のコマンドを入れてシンボリックリンクにでもしたいなぁ、と思いやってしまいました。

# cd /libexec
# mv ld-elf.so.1 ld-elf.so.1.orm (ormではなくorgのタイプミス…今後オルムファイルと呼びましょう。)

そして、シンボリックリンクでも張ろうと思った矢先、

# cd /
# mv libexec libexec.orm
ELF interpreter /libexec/ld-elf.so.1 not found
Aborted.

なぬ……………………………………………………。

これ、とんでもなく大事なファイルなんですね。（泪
調べたら、ld-elf.so.1さんはFreeBSDのバイナリを実行するのにとても大事そうなファイルなんだそうです。

おかげで、cpもlsもmvもなにもできないし、新たにsshでログインしてもまるでダメ。
あーあ、CD起動でなおさなくちゃいけないのかなぁとか思った矢先、そうだlinx_baseがたしか入っていたな、FreeBSDのELFバイナリじゃなければ…ということで、以下のコマンドを入れてみるわけです。

# /compat/linux/bin/bash
bash#

助かった…。ありがとうLinuxカーネルさん。あんたにちょっとだけ感謝するよ。

その後、慣れないbashでなんとかシンボリックリンクを作って逃げました。

うーん、これとても驚異ですね。。。まさしく「アキレス腱」です。