プログラマのつぶやき

日本ベリサインは、8月31日「旧来仕様のサーバIDの受付・発行期間の延長」および「1024bitRSAのCSRの受付期間の延長」を実施することを発表しました。

https://www.verisign.co.jp/ssl/about/20100128b.html

これにより、2010年10月11日(予定)の仕様変更以降は、公開鍵長に2048bitRSAを利用した新仕様の製品に加えて、旧来仕様のサーバIDも選択することができるようになります。

発行条件としては、
1.「グローバル・サーバID 」と「セキュア・サーバID」
2.有効期間が2013年12月31日を超えないことを条件に当面の間発行を継続する。
3.発行終了時期については未定。
4.「1年間有効」なサーバIDを選択した場合のみ
ということです。

元々勧告の中心となっていた「EV SSL証明書」は今回の対象から外され、現状でも2048bitしか発行されません。

日本ではモバイルショッピングが急速に広がった影響がかなり大きかったのでしょうか。まだまだ年末まで混乱が続きそうです。

蛇足ですが、ここ最近の円高により海外経由の安いSSL証明書がさらに安く入手できるようになっています。格安SSL証明書は今が狙い目！？

Virtual Server 2005 R2上にCentOS5.5をインストールして、PostfixとDovecotでメールサーバーを組みました。

が・・・・・Dovecotが頻繁に落ちるのです。

dovecot: pop3-login: Time just moved backwards by 5 seconds. I'll sleep now until we're back in present. http://wiki.dovecot.org/TimeMovedBackwards
dovecot: auth(default): Time just moved backwards by 4 seconds. I'll sleep now until we're back in present. http://wiki.dovecot.org/TimeMovedBackwards
dovecot: Time just moved backwards by 6 seconds. This might cause a lot of problems, so I'll just kill myself now. http://wiki.dovecot.org/TimeMovedBackwards

こんなエラーメッセージが続きます。

意味は「時間が○秒戻ったので私(Dovecot)は停止します」って、勝手に死ぬなよー

Virtual Server上に入れたCentOSはクロックの割り込みがうまく行かず、時間がすぐに大幅に狂ってしまいます。

そこでNTPサービスをインストールしましたが、時間が狂いすぎるのか同期できず、仕方なしにバッチで強制的に合わせていました。

# vi /etc/crontab
---
*/10 * * * * root ntpdate 219.164.211.137 > /dev/null 2>&1
---

しかし、エラーメッセージにある「http://wiki.dovecot.org/TimeMovedBackwards」を見てみると、このntpdateコマンドがいけないようですね。

急な同期がダメなのは次のホームページが参考になります。
http://www.ys-network.info/?p=996

このページに死んだDovecotを監視するバッチがあったのでセットします。

# vi /root/dovecot_check_restart.sh
---
#!/bin/sh

HOST='localhost'
#PORT=110
PORT=143
#HP=@$HOST:$PORT
HP=:$PORT
echo 'Checking to see if Dovecot is up...'
if ( lsof -Pni $HP -s TCP:LISTEN 2>&1 >/dev/null ); then
echo 'Dovecot is up';
else
echo 'Dovecot is down, restarting...';
/etc/init.d/dovecot restart
logger -p mail.info dovecot_check_restart.sh restarting Dovecot
fi
---
# chmod 700 dovecot_check_restart.sh
# vi /etc/crontab
---
* * * * * root /root/dovecot_check_restart.sh 2>&1 > /dev/null
---
# service crond restart

これで自動復帰するようになったDovecotですが、実際に接続して使用するとやはり途中で切断されることがしばしば・・・・

さらに調べていると「Virtual Machine Additions For Linux 2.0」で親ホストと同期するのがいいみたい

ということで

参考サイト
http://tnt-blog.at.webry.info/200801/article_3.html
http://www.microsoft.com/downloadS/details.aspx?FamilyID=bf12642f-77dc-4d45-ae4e-e1b05e0a2674&displaylang=en

まずはダウンロードした「VMAdditionsForLinux_32Bit.msi」を親ホスト(Windows Server 2003 R2)にインストールします。

インストールしたフォルダ内のISOファイル(C:\Program Files\Microsoft Virtual Server\Virtual MachineAdditions\VMAdditionsForLinux.iso)をCentOS5.5のCD-ROMにマウントします。

ここからは内部コマンドです。
# mount /dev/cdrom
mount: /etc/fstab や /etc/mtab 内に /dev/hdc を見つけられません

このコマンドだとエラーになりました。

# mkdir /mnt/cdrom
# mount /dev/cdrom /mnt/cdrom/
mount: ブロックデバイス /dev/cdrom は書き込み禁止です、読込み専用でマウントします

CDROM領域を作成してマウントすると読込み専用でマウントされました。

# cd /mnt/cdrom/
[root@fsmail cdrom]# ls
install.sh vmadd-kernel-module-RHEL-2.0-1.i386.rpm
vmadd-full-2.0-1.i386.rpm vmadd-scsi-2.0-1.i386.rpm
vmadd-full-RHEL-2.0-1.i386.rpm vmadd-shutdown-2.0-1.i386.rpm
vmadd-heartbeat-2.0-1.i386.rpm vmadd-timesync-2.0-1.i386.rpm
vmadd-kernel-module-2.0-1.i386.rpm vmadd-x11-2.0-1.i386.rpm

多くのRPMパッケージが入っていますね。

[root@fsmail cdrom]# ./install.sh

シェルがあったので実行してみましたが・・・・何も起きませんでした。

そこで１つずつインストール。依存関係のあったkernel-devel をUPDATE

# yum install kernel-devel
kernel-devel i686 2.6.18-194.11.1.el5 updates 5.4 M

次の順で4つのRPMパッケージをインストールしました。

# rpm -ivh vmadd-kernel-module-RHEL-2.0-1.i386.rpm
# rpm -ivh vmadd-heartbeat-2.0-1.i386.rpm
# rpm -ivh vmadd-shutdown-2.0-1.i386.rpm
# rpm -ivh vmadd-timesync-2.0-1.i386.rpm

残念.....CentOS5.5には入らないようです。

これが入ればそのまま使用と思いましたが、諦めます・・・

最近仕事でVPSにWeb、メール(Postfix、Dovecot)、Webメール、メーリングリスト(Mailman)とインストールしたのだが・・・

本番が始まると突然のサービス停止に時々見舞われて、極めて不安定な状態です。

どうもメーリングリストの設定なのか相性なのか、ここが起因になって他のサービスが停止するようです。

ということで、死活監視を行うことになったのですが、今回はCronのみで死活監視を行うことに挑戦しました。

cronの編集は「# vi /etc/crontab」を前提としています。

Webの死活監視
0 * * * * root wget -O - (URL) > /dev/null 2>&1 || echo `date +\%Y/\%m/\%d_\%H:\%M:\%S` > /dev/null | tee -a /var/log/service_watch.log | service httpd restart > /dev/null | tee -a /var/log/service_watch.log

毎時0分に起動します。Wgetコマンドにより(URL)に指定したコンテンツを取得、取得できなかった場合は、ログファイル(/var/log/service_watch.log)に時刻とサービス再起動状態を記録します。「tee」コマンドの「-a」はファイルに追記するオプションです。

smtpの死活監視
1,11,21,31,41,51 * * * * root (sleep 2;echo "quit") | `telnet 127.0.0.1 25 >& smtp_status`;if [ `grep -c '220' smtp_status` != 1 ]; then service postfix restart; logger -t smtp "crond check - smtp service restart"; fi; > /dev/null 2>&1

1分から10分おきに実行します。quit入力を2秒後にセットし、ローカルの25番ポートに接続します。正常に接続できれば、エコーの中に「220」が入るので、それがない場合は接続できなかったと判断して、Postfixの再起動をします。ログは標準のmessageログに指定したメッセージ(crond check - smtp service restart)で書き込まれます。

pop3の死活監視
2,12,22,32,42,52 * * * * root (sleep 2;echo "quit") | `telnet 127.0.0.1 110 >& pop3_status`;if [ `grep -c 'Welcome' pop3_status` != 1 ]; then service dovecot restart; logger -t pop3 "crond check - dovecot service restart"; fi; > /dev/null 2>&1

2分から10分おきに実行します。quit入力を2行後にセットし、ローカルの110番ポートに接続します。正常に接続できれば、エコーの中に「Welcome」(独自のバナーメッセージ)が入るので、それがない場合に接続できなかったと判断して、Dovecotの再起動をします。ログは標準のmessageログに指定したメッセージ(crond check - dovecot service restart)で書き込まれます。

メーリングリストはサービスが起動していても、キューが詰まる現象があったので、1時間ごとに強制的に再起動させるようにしました。

10 * * * * root service mailman restart > /dev/null 2>&1

お盆の今日、母を連れて倶利伽羅不動尊の万灯会に行ってきました。

どのくらい混雑するのかわからなかったので早めに出かけましたが、着いたときはまだまだ空いていました。

蝋燭の点灯準備が進む中、境内？を一通り見て回ると、津幡町文化財ともなっている古墳跡から全体を見下ろすことができました。

暗くなるまで二胡の演奏などを楽しみ、ようやく蝋燭の明かりがきれいな夜になりました。

先程の地点からみても、境内いっぱいの明かりの列がきれいです。

本堂での万灯会のあと、

池で燈籠流しが始まりました。

読経の流れる中、燈籠流しは厳かに続きました。流れが少ない池ですので、燈籠は湖岸に溜まりがちでしたが、良いセレモニーでしたね。

とはいえ、境内の一番人気！？はこちらのトロロだったり・・・するんですけど。

mod_rewriteモジュールでサイト全体をSSL対応(https)する「.htaccess」ファイルの書き方は・・・

RewriteEngine On
RewriteCond %{HTTP_HOST} ^free-style.biz$
RewriteCond %{HTTPS} off
RewriteRule ^(.*) https://free-style.biz/$1 [R=301,L]

条件として2行目の「HTTP_HOST」はあってもなくてもよいです。
3行目の「%{HTTPS} off」により「http://で始まっている」＝「https://で始まっていない」という条件になります。
4行目で絶対表示でURLを指定し、ルート以下のパスを「$1」として追加します。

さて、CakePHPサイトで「www」で始まるURLを「wwwなし」に変更してアクセスする場合の書き方を説明します。(/app/webroot/.htaccess)

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.free-style.biz$
RewriteCond %{HTTPS} on
RewriteRule ^(.*) https://free-style.biz/$1 [R=301,L]
RewriteCond %{HTTP_HOST} ^www.free-style.biz$
RewriteCond %{HTTPS} off
RewriteRule ^(.*) http://free-style.biz/$1 [R=301,L]
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php?url=$1 [QSA,L]

大まかな流れは
1.www付きをwwwなしにして再アクセスする(http://の場合)
2.www付きをwwwなしにして再アクセスする(https://の場合)
3.ディレクトリやフォルダが実在しない場合はindex.phpを実行する
となります。3は通常のCakePHPのままです。

条件(RewriteCond)とルール(RewriteRule)は何個も重ねて定義されますが、「[R=301,L]」により正常に再アクセスされた場合はここで一旦終了するようになります。

http://www.free-style.biz/でアクセスされた場合は、1番目で「http://free-style.biz/」に再アクセスされて一度終了し、「http://free-style.biz/」でアクセスされて3番目でindex.phpが実行されます。

この仕組みが理解できれば、htaccessを使いこなせるようになりますよ！

普段CakePHP(v1.3)を利用するにあたり、あまり考えずに使用している「.htaccess」ファイルについて解説します。

/(ルート)

RewriteEngine on
RewriteRule ^$ app/webroot/ [L]
RewriteRule (.*) app/webroot/$1 [L]

1行目「RewriteEngine on」はmod_rewriteモジュールを使用するためのスイッチです。
2、3行目はともに「RewriteRule」なので、書き換えルールの適用となります。意味は「app/webroot/ に移動する」となります。

/app/

RewriteEngine on
RewriteRule ^$ webroot/ [L]
RewriteRule (.*) webroot/$1 [L]

ここはルートとほぼ変わりないですが、書き換えルールが「webroot/に移動する」となっています。

/app/webroot/

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php?url=$1 [QSA,L]

一般公開するときはここをルートにすることが推奨となっています。その理由はこのファイルにあります。

1行目「RewriteEngine on」はmod_rewriteモジュールを使用するためのスイッチです。
2、3行目の「RewriteCond」は書き換えルールを適用するための条件を定義しています。2行目はパラメータ「-d」により、実際にディレクトリが存在しない場合、3行目はパラメータ「-f」により、実際にファイルが存在しない場合となり、両方合わせて、指定されたURLパスに実際にディレクトリもファイルも存在しない場合となります。
4行目で書き換えルールが指定されています。「^(.*)$ index.php?url=$1」は同フォルダ内の「index.php」を実行するという意味ですが、「?url=$1」の「$1」が何なのか？よくわかりませんでした。

Perlを使用するには当たり前の正規表現らしいのですが、「$1」の「$」は末尾を示すわけではなく、「$1」で「要素の1番目を適用する」ということになります。

要素の1番目とは「^(.*)$」のことです。index.phpの前に半角スペースがあり、半角スペースでつなげていくことにより要素を複数定義できます。「^(.*)$」は「先頭から0文字以上の文字列を末尾まで」という意味です。つまり、ルート以下のパスがここに入ります。

CakePHPでは必ずindex.phpから始まると誤解している人がいますが、これはある意味で正しく、ある意味で間違っています。

CakePHPのフレームワーク内の制御としてはindex.phpが常に実行されます(正しい部分)が、webwoot配下に実際に配置されたhtmlファイルや画像ファイルはそのまま表示され、index.phpは実行されません(間違っている部分)。

静的なhtmlファイルのみではなく、phpファイルであっても、webroot配下に配置すれば実行することができます。ただし、ルートが「/app/webroot/」まで下げられていないと、CakePHPのフレームワーク外ではURLに「/app/webroot/」が表示されてしまうことがあります。

先月まで北國新聞と富山新聞で531回連載されてきた「炎天の雪」が今月集英社より刊行されました。

本日、しいのき迎賓館の三階セミナールームで、刊行記念となるトークショーとサイン会が開催されました。

会場の手前ではうつのみや書店が諸田玲子さんの本を販売し、奥で受付をしていました。サイン会への参加は本の購入者なので、さっそく発売されたばかりの「炎天の雪」を購入しました。

廊下には連載中の挿絵を担当した横田美砂緒さんの挿絵が・・・

この挿絵が物語を盛り上げてくれたのですよね。書籍になったら・・・やはり挿絵はなくなりました。残念です。

カバーの絵だけが書き下ろしの横田さんの晋作です。

トークショーのほうは泉鏡花記念館の青山館長と進められました。自分は金沢が舞台の時代小説ということで興味はあったにしても、初めて最後まで読んだ新聞小説であったので、どこにそんなに興味を持ったのだろうと思っていました。小説の舞台となった江戸の宝暦というのは、飢饉や大火など貧困にあえいだ時代であり、泰平から変化への過渡期となった時期ですが、現代も不況が長引き、9・11以降の社会不安があって、そのあたりは時代背景が似ているところは、実は意図的だったそうです。

構想時には一年ぐらいの泥棒の物語だったそうですが、進むにつれ、将軍の母や加賀騒動に巻き込まれた子供たちが活き活きと活動し、諸田さんによって一番の長編となったそうです。書くときは1か月分以上で書き上げていたらしく、連載とはいえ、引き込まれる展開はそこらにもあったそうですよ。

1時間の楽しいトークショーはあっという間に終わり、本の購入者に向けてサイン会が始まりました。

「炎天の雪」は上下2冊なのですが、2冊ともにサインしていただきました。作家さんの直筆はとてもきれいな字とは言えない方も多いのですが、諸田さんの字はとてもきれいな字ですね。

トークショーへの参加者は先着100名でしたが、サイン会に参加したのは30名弱でしょうか？私は17番目でしたが、滅多に参加できない作家さんのトークショーに参加していながら勿体無い話です。

上下で4000円ですよ。会いたいといってもそう簡単に会える方でもないのに・・・

その分一人ひとりはゆっくりとサイン書いていただけたので良かったです。

「炎天の雪」は上下2冊ですが、531回の新聞連載をそのまま収録したのでは2冊には収まらないそうです。

そうです。この単行本化するにあたり、すべてを推敲しおなしているんですよ。新聞連載と比べながら読む楽しみもあるんですよ。金沢の時代小説の決定版ですので、そのうち「炎天の雪」の観光スポット案内でも作りましょうか。

泉鏡花記念館と金沢能楽美術館で開催中の「鏡花と能楽」ですが、昨日より後期展が始まったので、両館見てきました。後期展では「照葉狂言」と金谷御殿を中心に展示されていました。

ベリサインと契約している会社に不定期に送信されてくる「VeriSign　Letter」、その7月号に気になることが書かれていました。

---

Googleのhttps化がおよぼす影響とは？

ウェブサイト運営者の多くはアクセスログ解析ツールを使って訪問者がどのサイトから来るのか、どんなキーワードで検索してくるのかを日々確認されていると思います。そこで本日はGoogle社が新しく開始したSSL暗号化対応の検索サイトの登場によって、これまでのログ解析結果にどのような影響が出てくるのか少し触れてみたいと思います。

5月21日よりGoogle社はエンドユーザのプライバシーを保護するため、SSL暗号化対応のベータ版検索サービスを立ち上げました。エンドユーザの検索キーワードと検索結果はSSL暗号化によって通信経路上の第三者から守られます。その一方で、非SSL（URLがhttp://から始まる）のサイト運営者には、このサイトからの訪問者がどこから来たのか、どんなキーワードを検索したのかが分からなくなってしまい、ウェブマーケティング活動に支障をきたす恐れがあります。

通常Internet ExplorerやFirefoxなどのブラウザは、サイト訪問者が直前に訪問していたURLをリファラと呼ばれる情報としてウェブサーバに送信します。ところが直前のURLがhttpsから始まるSSLサイトの場合、非SSLサイトへ遷移してもリファラを送信しない仕様となっています。これはブラウザのセキュリティ仕様による動作です。例えばプログラムが稼動しているサイト上ではURLにセッションIDなどプライバシー情報につながりやすいパラメータを含むことがしばしばあります。そのような場合でも、前出の仕様によってSSL暗号化されたサイトのセッションIDなどが通信経路上の第三者に渡ってしまう事を防げます。

しかし、サイト運営者にとってリファラはSEOやレコメンド機能などウェブマーケティング活動の重要な基礎データとなります。そこでこれまで通りリファラを取得するためにはサイト全体をSSL化するがひとつの解決手段となります。

Google社のSSL検索サイトの利用者の数はまだまだ多いわけではないと思いますので対応を急ぐ必要はなさそうですがプライバシー意識の高まりによって今後SSLがどのように利用されてゆくようになるのか、気に留めてみるのも良いかもしれません。

-->> Google社のSSL検索サイトを試してみる
　　 http://vmail.verisign.co.jp/c?c=9229&m=37718&v=a8328336

---

SSL証明書購入しないといけないのか？お金かかるな。

というぐらいにしか思わないかもしれませんが、SSL導入するときは、
・SSL証明書をドメイン１つにつき、１つ購入する
・ドメイン１つにつき、１つのグローバルIPアドレスを取得する
という２つの難関を突破しないといけません。

マルチドメイン対応のSSL証明書があるではないか？

と思う方もいると思いますが、マルチドメイン対応証明書は携帯電話には対応しません。今時、モバイル対応できない証明書に意味があるとは思えません。

もっと深刻なのは、グローパルIPの問題です。現在IPv4のIPアドレス枯渇問題が間近に迫る中で、すべてのWEBサイトにグローバルIPアドレスを準備することは到底無理です。

この問題に対応しないデメリットは・・・

リファラが取得できないことにより、アクセス解析ができなくなることです。Google Analyticsではサイトに来た経緯として。「検索エンジン」があり、さらにどのような「キーワード」で検索されて訪問したのかが分かります。

しかし、SSL対応のGoogleから来たユーザーは「https」から「http」にリファラ情報を引き継げないことにより、直接訪れたユーザーのように見えるということです。検索された「キーワード」もわからないので、どうページを変更していくか方針が立てづらくなります。

そもそもGoogleの意図はどこにあるのか？
建前は「エンドユーザのプライバシーを保護するため」となっていますが、途中で解読できなくなるため「自社検索サイトで入力された単語も含めた情報の独占」なのか、それとも自社広告を介しての「Google CAの販売」なのか、後者は話が飛躍しすぎですが、かなり影響は大きいでしょうね。

いずれにしてもプライバシー保護の流れは止まらないでしょうから、近い将来すべてのWEBサイトはSSL化することになりそう！？です。

それともうひとつ、

---

携帯電話でSSL通信ができないと何が起こるのか？ ～ケータイSSL接続検証サービスを開始しました～

携帯電話端末からインターネットアクセスをする際に、SSLで通信を暗号化する場面は多々あります。しかし、携帯電話端末に組み込まれた“ルート証明書”によってはSSLサーバ証明書との暗号化通信ができず、携帯電話端末の画面にエラーが表示されます。エラーの内容は各携帯電話端末の通信方式や機種によって異なり、接続を終了してしまう機種もあります。また、SSLサーバ証明書や中間証明書のサーバ設定を間違った場合にもエラーが表示されます。

弊社では各種携帯電話端末からお客様指定の携帯電話向けサイトにアクセスをして、SSL暗号化通信が正しく行えることを検証するサービスを開始しました。接続検証に関しては、多数の携帯電話端末機種を保有する必要があり検証を正確に実施するための専門的な知識が必要になります。携帯電話向けサイトオープン前の実機検証、お客様からの問い合わせに即時回答するために対応機種を特定しておきたいなどのニーズに応えるサービスです。詳しは以下をご覧ください。

-->> 日本ベリサインの「ケータイSSL接続検証サービス」の詳細はこちら
　　 http://vmail.verisign.co.jp/c?c=9230&m=37718&v=c6af2618

---

なんかおかしな気分です。証明書の携帯端末への対応度調査は日本ベリサイン社自身が実施して発表するべき作業です。

自社サイトの証明書がベリサインであれば、サイトのコンテンツにより証明書が影響を受けるわけではないでしょう。

と思っていたら、ベリサイン以外のSSL証明書を使用していても申し込みはできようです。ということは、結果が悪いから自分ところの証明書に替えましょう！と営業かけられるためにお金払う人はいるでしょうか？

日本のSSL証明書として最も影響のある、日本ベリサイン社の公開鍵長2048bitへの仕様変更日が決まりました。

2010年10月11日(月)

祝日を選んだのは企業の移行に一番支障を来たさないようにという配慮でしょうが、思っていたよりも早いですね。営業情報としては少し前に10月の早い時期という話は聞いていましたが・・・

ベリサイン サーバIDおよびコードサイニング証明書製品における公開鍵長などの仕様変更について(続報)https://www.verisign.co.jp/ssl/about/20100128b.html

それにしても、今回気になるのは、

「5. 旧来仕様のサーバIDの発行継続について」

の内容についてです。

「米国NISTでは1024bit RSAの公開鍵暗号方式の利用を、一定の条件下において2013年末までこれを延長して利用を認めるガイドラインのドラフトを発表しており、現時点では(2010年7月15日時点)パブリックコメントが受け付けられております。この結果が反映された新しいガイドラインは、近い将来に発表される見込みです(詳細時期は現時点では未定)。
弊社では引続き、お客様のセキュリティへのご要望にお応えするために、2048bitRSAへの移行を、上記の通り進めさせていただきますが、同時に、上記のNISTガイドラインのアップデートを踏まえ、「1024bitRSAのCSRの受付期間の延長」および「旧来仕様のサーバIDの受付・発行期間」を延長し、お客様のセキュリティポリシーおよびニーズによっていずれかを選択いただける様にすることを検討しております。」

どういうこと！？でしょうか。

今までは2048bitに完全移行するようなアナウンスでしたが、従来の1024bitも選択できるように検討中に変更されています。ということは、結局しばらくは両方購入できるということのようです。

サイバートラスト社はこの件について、話し合いで1024bitの延長をしたいようなアナウンスを流していますが、ベリサイン社も近い話になってきました。

日本で最も早く2048bitへ仕様変更を表明していたジオトラスト社(販売は日本ベリサイン社)は先週21日と予告された切替日が23日に直前に変更されました。
http://www.geotrust.co.jp/news/2010/20100129.html

今日確認して更新されていないところを見ると、完全に2048bitへ切替が終了したようです。

暑い日が続きますね。今日は博物館めぐりをしてきました。

始めは室生犀星記念館で開催中の「軽井沢の日々」です。犀星の第二の故郷であり、夏の避暑地として別荘を建てた軽井沢に関係する作品や遺品が展示されています。

続いて石川県立歴史博物館で開催中の「トキ舞う空へ　鳥と人の文化史」です。石川県は本州最後のトキの生息地であり、現在分散飼育地として8羽のヒナが誕生しています。

トキの剥製や資料だけではなく、藩政期の鷹狩りの資料などが展示されていました。鷹狩りには「ハヤブサ」や「オオタカ」が使用されていたそうですが、最上級の獲物が「ツル」だったそうです。獲物にはランクがあり、筆頭の「ツル」から雁、鴨となっていたそうです。

剥製もいくつか展示されており、「クマタカ」や「イヌワシ」の大きさには圧倒されますね。

次に前田土佐守家資料館で「前田土佐守家の子女たち」を見ました。今はⅠ期「子女たちのつとめ」が始まったばかりです。藩政期の子女たちの役目は第一に家の存続でした。

次に金沢ふるさと偉人館で開催中の「蓮田修吾郎の生涯」を見てきました。蓮田修吾郎氏は金沢市野田町生まれの金属造形の第一人者らしいです。「金属造形」という聞きなれない言葉ですが、県内には金沢駅西口や北國新聞ビル前などになるステンレス製のモニュメントなどが代表作です。

石川県立博物館前の広場にあるこのモニュメントも蓮田氏の代表作だそうです。普段よく目にするものだったんですね。

次に中村記念美術館で「大樋長左衛門展」を見ました。今年10代大樋長左衛門氏から同館に自作の茶碗34点を寄贈したことを記念して開催されている特別展です。同館所蔵の作品と借用作品を合わせて60点の作品を一堂に展示しています。

中でも黒の茶碗が魅力的で、「内不二絵黒茶碗」という黒の茶碗の内側に富士山が浮かび上がっているような作品でした。

最後に金沢能楽美術館で「鏡花と能楽」を見ました。先日見た泉鏡花記念館が第一会場で、こちら能楽美術館が第二会場となっています。鏡花が生きた時代の能楽の状況を紹介するような内容で、金沢城二の丸や金谷御殿の絵図（能舞台が描かれている）も展示されていました。

今日北陸は梅雨明けしました。いきなりの今年一番の夏日でした。

銀色の卵でおなじみの福井県勝山にあるアジア最大の恐竜博物館です。

夏休み直前、親子連れがたくさん遊びに来ていました。地元ではレジャー施設としてすっかり定着しましたね。

今年は開館10周年も迎えて、今年も夏休みの特別展が開催されていますが、今日は関連行事として、中国科学院古脊椎動物古人類研究所の董枝明(ドン チミン)教授による「アジアの恐竜」が開催されました。

中国を含めたアジアはここ数年で恐竜研究が飛躍的に盛んになりました。そのアジアの恐竜発掘の現状をお話いただきました。

中国には６つの恐竜博物館と４つの恐竜公園があるそうです。うらやましいですね。

講演会後には特別展「アジア恐竜時代の幕開け」を見てきました。

今回は中国で発掘された骨格標本を中心に展示されています。巨大恐竜がテーマのひとつでありますので、人の背丈もあるような竜脚類の大腿骨なんかも展示されていました。

自分の子供の頃の竜脚類と言えば、「ブロントサウルス」や「ブラキオサウルス」ぐらいでしかが、その後種類が増えてよくわからない状態です。今回は中国で発見された「ルーフェンゴサウルス」がメインです。

竜脚類のほかに獣脚類の骨格標本もありますよ。

新聞報道もされた勝山の3つ目の恐竜で、日本で始めて竜脚類として名前のついた「フクイティタン」の化石も展示されていました。

卵の化石などもあり、今回は10周年という記念すべき特別展だけあって展示も充実していますね。

携帯サイトで、「Flash待ち受け」「画像待ち受け」「デコメテンプレート」の3種類のダウンロード回数をカウントするサイトを作成したときの話。

それぞれのダウンロード回数をアクセスログの行数(つまり画面に表示した時点でダウンロード)で判断することになった。

その適用方法を紹介します。

# vi /etc/httpd/conf/httpd.conf

---

#
# For a single logfile with access, agent, and referer information
# (Combined Logfile Format), use the following directive:
#
SetEnvIf Request_URI "decome\.dmt" decome
SetEnvIf Request_URI "decome\.hmt" decome
SetEnvIf Request_URI "decome\.khm" decome
SetEnvIf Request_URI "flash0\.swf" flash
SetEnvIf Request_URI "waiting0\.gif" waiting
CustomLog logs/decome1_log combined env=decome
CustomLog logs/flash_log combined env=flash
CustomLog logs/waiting_log combined env=waiting
CustomLog logs/access_log combined　　　　　　　　　　　　　

→mod_setenvif を使用して該当のファイル名がアクセスログに記録されるタイミングに、各個別ファイルと「access_log」に記録されるようにします。一番後ろにつけた名前(env)によって振分をおこないます。

・・・
CustomLog "| /usr/sbin/rotatelogs /home/fs/www/accesslog/access_log.%Y%m%d 86400 540" combined
CustomLog "| /usr/sbin/rotatelogs /home/fs/www/accesslog/decome0_log.%Y%m%d 86400 540" combined env=decome
CustomLog "| /usr/sbin/rotatelogs /home/fs/www/accesslog/flash_log.%Y%m%d 86400 540" combined env=flash
CustomLog "| /usr/sbin/rotatelogs /home/fs/www/accesslog/waiting_log.%Y%m%d 86400 540" combined env=waiting

→バーチャルホストを使用している場合は、ここにも「CustomLog 」を追加します。最後に「env」を忘れると、うまく振分られないことがありますので、忘れずにつけましょう。

---

後はできたファイルの行数を数えれば各ダウンロード回数となります。
(注)Basic認証をかけた場合は1回のアクセスで2行追加される場合があります。

米マイクロソフトは2010年7月12日（米国時間）、OEM版Windows 7に付随する「ダウングレード権」の提供期限を延長する方針を明らかにした。

ダウングレード権とは、最新OSのライセンスによって、過去のOSを利用する権利のこと。パソコンにプリインストールされるOEM版Windows 7の場合、Professional以上のエディションでダウングレード権が付与され、Windows Vista BusinessやWindows XP Professionalなどへのダウングレードが可能になる。

現在もなお、メーカーから「Windows XP Professional搭載パソコン」の販売が続いているのは、このダウングレード権を行使しているためだ。こうしたWindows XP搭載パソコンの販売期間が、大幅に延長されることになる。

---

原因は今に至っても企業のWindowsXPの利用率が80％を越えることがあるようだ。しかし、また延長してマイクロソフトはどうしたいのでしょうね？

CakePHP バージョン1.3.2をインストールしてみました。

データベース設定ファイルのテンプレート(config/database.php.default)には、バージョン1.2.Xと同様のデータベースが記載されています。

---

* Database configuration class.
* You can specify multiple configurations for production, development and testing.
*
* driver => The name of a supported driver; valid options are as follows:
* mysql - MySQL 4 & 5,
* mysqli - MySQL 4 & 5 Improved Interface (PHP5 only),
* sqlite - SQLite (PHP5 only),
* postgres - PostgreSQL 7 and higher,
* mssql - Microsoft SQL Server 2000 and higher,
* db2 - IBM DB2, Cloudscape, and Apache Derby (http://php.net/ibm-db2)
* oracle - Oracle 8 and higher
* firebird - Firebird/Interbase
* sybase - Sybase ASE
* adodb-[drivername] - ADOdb interface wrapper (see below),
* odbc - ODBC DBO driver

---

MySQL、SQLite、PostgreSQL、SQL Server、DB2、Oracle、Firebird、Sybase、ADODB接続、ODBC接続

さてさて、実際にデータソースを覗いてみましょうか。
cake/libs/model/datasources/dbo/

SQL Server、MySQL、Oracle、PostgreSQL、SQLite ・・・・・・・

・・・・・・・

なんか少なくなったぞ？？

調べてみると、他のデータソースはインターネットからダウンロードして入れるようです。

http://github.com/cakephp/datasources/tree/master/models/datasources/dbo/

ADODB接続、DB2、Firebird、ODBC接続、SQLite3、SQL Server、Sybase　・・・　と。

SQL Serverは「dbo_mssql.php」のほかに「dbo_sqlsvr.php」が新しく用意されたようですね。

全部入れると、かなりにぎやかな状態になりました。

しかし、標準でインストールされていないデータソースについては、今後データソースがバージョンアップされてもCakePHP本体に入っていないということになりますので、自分で時々のぞきに来る必要がありそうですね。

今回は、CentOS上のCakePHPからWindowsServer上のSQL Serverにネイティブ接続してみたかったのですが、新しいデータソースが出たのも役立たず・・・、結局LinuxにはSQL Serverに接続するネイティブドライバが容易されていませんから。

そう考えると、「SQL Server (dbo_mssql.php)」「SQL Server (dbo_sqlsvr.php)」「ADODB接続」については、Windows専用ということですね。まぎらわしいなあ・・・もう。

今日は3時から9時までデータベースのメンテナンスがあったようですが、その後も断続的につながらず・・・・

メンテのキャラはかわいいけど

RTX1100の設定不足でNTP同期できなかった問題が解決したところで、NTPサーバの設定をまとめておきます。

OS：CentOS 5.5 最小インストール
NTPサーバ：ビジネスぷらら
プライマリ：ntp2.plala.or.jp
セカンダリ：ntp1.plala.or.jp

NTPをインストールします。
# yum install ntp

今日現在インストールされるバージョンは「4.2.2p1-9.el5.centos.2.1」となります。

設定ファイルを編集します。
# vi /etc/ntp.conf

既存のIPv4、IPv6用の問い合わせをコメントアウトし、すべての外部からの問い合わせの拒否を追加します。
# Permit time synchronization with our time source, but do not
# permit the source to query or modify the service on this system.
#restrict default kod nomodify notrap nopeer noquery
#restrict -6 default kod nomodify notrap nopeer noquery
restrict default ignore

IPv6用のループバックアクセスをコメントアウトします。
# Permit all access over the loopback interface. This could
# be tightened as well, but to do so would effect some of
# the administrative functions.
restrict 127.0.0.1
#restrict -6 ::1

今回使用するビジネスぷららのNTPサーバを追加します。
# Hosts on local network are less restricted.
#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
restrict 219.164.211.137 mask 255.255.255.255 nomodify notrap noquery
restrict 219.164.211.129 mask 255.255.255.255 nomodify notrap noquery

既存のNTPサーバをコメントアウトし、ビジネスぷららのNTPサーバを追加します。
# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
#server 0.centos.pool.ntp.org
#server 1.centos.pool.ntp.org
#server 2.centos.pool.ntp.org
server ntp2.plala.or.jp
server ntp1.plala.or.jp

最後にローカルで同期するのを停止します。
# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available.
#server 127.127.1.0 # local clock
#fudge 127.127.1.0 stratum 10

自動起動するようにデーモンを設定します。
# chkconfig --level 3 ntpd on

デーモンを起動する
# service ntpd start

１０分後ぐらいに同期を確認します。
# ntpq -p
remote refid st t when poll reach delay offset jitter
=============================================================
+ntp2.plala.or.j 202.234.233.109 4 u 30 64 377 14.117 23.350 7.381
*ntp1.plala.or.j 202.234.233.109 4 u 33 64 377 13.983 29.240 3.461

先頭に「*」が付いたNTPが現在の同期サーバーとして、「+」が付いたNTPが予備サーバーとして正常に同期したことを示しています。

現在の時刻を確認して終了です。
# date

WEBサーバをWindows ServerからCentOSに乗せ替えたのを機に、ログの時間を正確に合わせようとNTPサーバを組んでみましたが・・・・

なぜが同期しません。なぜ？なぜ？

プロバイダはビジネスぷららなので、プロバイダの提供するNTPサーバを利用してみます。
http://biz.plala.or.jp/support/manu/index.html

プライマリは「ntp2.plala.or.jp」、セカンダリは「ntp1.plala.or.jp」となります。

しかし、ntpdateの詳細コマンドの実行結果でも「no server suitable for synchronization found」となります。

# ntpdate -d ntp2.plala.or.jp 12 Jul 23:40:50 ntpdate[8159]: ntpdate 4.2.2p1@1.1570-o Sat Dec 19 00:58:17 UTC 2009 (1) Looking for host ntp2.plala.or.jp and service ntp host found : ntp2.plala.or.jp transmit(219.164.211.137) transmit(219.164.211.137) transmit(219.164.211.137) transmit(219.164.211.137) transmit(219.164.211.137) 219.164.211.137: Server dropped: no data server 219.164.211.137, port 123 stratum 0, precision 0, leap 00, trust 000 refid [219.164.211.137], delay 0.00000, dispersion 64.00000 transmitted 4, in filter 4 reference time: 00000000.00000000 Thu, Feb 7 2036 15:28:16.000 originate timestamp: 00000000.00000000 Thu, Feb 7 2036 15:28:16.000 transmit timestamp: cfe5a7f6.24db4890 Mon, Jul 12 2010 23:40:54.143 filter delay: 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 filter offset: 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 delay 0.00000, dispersion 64.00000 offset 0.000000 12 Jul 23:40:55 ntpdate[8159]: no server suitable for synchronization found

いろいろと調べてみると、YAMAHAのRTX1100の設定が問題だとわかりました。

NTPサーバを公開するフィルタ/NTPサーバに接続するフィルタを教えてくださいhttp://www.rtpro.yamaha.co.jp/RT/FAQ//IP-Filter/public-ntp-server.html

なるほど！DNSと同じでUDP通信のNTPは戻りパケットはestablishedでは通過できないのか。

ということで、rejectの前に
ip filter 33 pass * 210.160.212.153-210.160.212.158 udp ntp ntp,1024-65535
を追加して、

pp select 1
ip pp secure filter in 11 12 13 14 15 16 21 22 23 24 25 31 32 33 34 100

INフィルタに定義を追加しました。

ふたたび・・・・・

# ntpdate -d ntp2.plala.or.jp 12 Jul 23:45:08 ntpdate[8172]: ntpdate 4.2.2p1@1.1570-o Sat Dec 19 00:58:17 UTC 2009 (1) Looking for host ntp2.plala.or.jp and service ntp host found : ntp2.plala.or.jp transmit(219.164.211.137) receive(219.164.211.137) transmit(219.164.211.137) receive(219.164.211.137) transmit(219.164.211.137) receive(219.164.211.137) transmit(219.164.211.137) receive(219.164.211.137) transmit(219.164.211.137) server 219.164.211.137, port 123 stratum 4, precision -17, leap 00, trust 000 refid [219.164.211.137], delay 0.03940, dispersion 0.00006 transmitted 4, in filter 4 reference time: cfe5a88c.cf4080f9 Mon, Jul 12 2010 23:43:24.809 originate timestamp: cfe5a8e9.6788ca3e Mon, Jul 12 2010 23:44:57.404 transmit timestamp: cfe5a8f4.abc21187 Mon, Jul 12 2010 23:45:08.670 filter delay: 0.04099 0.03940 0.03972 0.03954 0.00000 0.00000 0.00000 0.00000 filter offset: -11.2734 -11.2734 -11.2736 -11.2734 0.000000 0.000000 0.000000 0.000000 delay 0.03940, dispersion 0.00006 offset -11.273424 12 Jul 23:45:08 ntpdate[8172]: step time server 219.164.211.137 offset -11.273424 sec

今度は「step time server 219.164.211.137 offset -11.273424 sec」にメッセージが変わったので、NTPサーバと通信できたようだ。

さらに、しばらく待って・・・

# ntpdate -d ntp2.plala.or.jp 13 Jul 00:05:15 ntpdate[8265]: ntpdate 4.2.2p1@1.1570-o Sat Dec 19 00:58:17 UTC 2009 (1) Looking for host ntp2.plala.or.jp and service ntp host found : ntp2.plala.or.jp transmit(219.164.211.137) receive(219.164.211.137) transmit(219.164.211.137) receive(219.164.211.137) transmit(219.164.211.137) receive(219.164.211.137) transmit(219.164.211.137) receive(219.164.211.137) transmit(219.164.211.137) server 219.164.211.137, port 123 stratum 4, precision -17, leap 00, trust 000 refid [219.164.211.137], delay 0.03911, dispersion 0.00008 transmitted 4, in filter 4 reference time: cfe5ac8f.106a8fc0 Tue, Jul 13 2010 0:00:31.064 originate timestamp: cfe5adab.ddec0b56 Tue, Jul 13 2010 0:05:15.866 transmit timestamp: cfe5adab.d5633482 Tue, Jul 13 2010 0:05:15.833 filter delay: 0.04726 0.03952 0.03952 0.03911 0.00000 0.00000 0.00000 0.00000 filter offset: 0.026731 0.026530 0.026451 0.026577 0.000000 0.000000 0.000000 0.000000 delay 0.03911, dispersion 0.00008 offset 0.026577 13 Jul 00:05:15 ntpdate[8265]: adjust time server 219.164.211.137 offset 0.026577 sec

「adjust time server 219.164.211.137 offset 0.026577 sec」

やった！！NTPが同期しましたよ。

今日帰って来たら自分の加入しているプロバイダ「ASAHIネット」から葉書が来ていました。

内容は・・・・

「固定IPアドレスサービス」ご利用料金改定のお知らせ

フレッツ・光プレミアム回線で固定ＩＰアドレスサービスを利用する場合、月額費用1,050円のなかで無料で利用できましたので、私も随分お世話になりました。

しかし、9月利用分より月額840円がかかるようになります。と言っても、月額合計1,890円という業界最安値ラインではあるのですが・・・

今はすでに別サービスで固定IP8個を契約しているので必要ないので解約します！

今回の案内はどうも「NTT西日本限定」だったようなのですが、NTT東日本地区は先に値上げになっていたのかな？

今日は映画の前売券を買ってきました。（特典は扇子ですよ）

今度の舞台は「東京」らしいですよ！

「バイオハザードⅣアフターライフ」 ゲームと同名のこの映画もついに4作目となり、独自の世界観を築いていますね。ついに3D進出です！！予告見たらスゴイ飛び出てたので期待大！ですね。

ということで前売りも当然3D上映のあるイオンサンシャインシネマかほくです。9月が楽しみです・・・

と、こちらは年末公開される「加賀藩御算用者」を描いたベストセラーの映画化です。キャスティングも有名どころを揃えて、地元では期待されての全国に先駆けて11月27日の公開となっています。

CA構築編、サーバ証明書編、と続いたクライアント証明の実現方法ですが、いよいよ「クライアント証明書」編の始まりです。

ユーザディレクトリに移動します。
# cd /usr/local/ssl

秘密鍵を2048bitで作成します。
# openssl genrsa -out client.private.pem 2048

---

Generating RSA private key, 2048 bit long modulus
.....................................................................+++
....+++
e is 65537 (0x10001)

---

秘密鍵を使用して署名リクエスト(公開鍵)を作成します。クライアント(ユーザ)単位に適用する証明書なので、ユーザ名がわかる名前を付けます。
# openssl req -new -key client.private.pem -out admin.free-style.biz.pem

---

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) [JP]:
→そのままEnterキー
State or Province Name (full name) [Tokyo]:
→そのままEnterキー
Locality Name (eg, city) [Shinagawa-ku]:
→そのままEnterキー
Organization Name (eg, company) [Fs DataCenter CA]:
→そのままEnterキー
Organizational Unit Name (eg, section) []:
→そのままEnterキー
Common Name (eg, your name or your server's hostname) []:
→ユーザ名(admin)を入力します。(各自お好みで)
Email Address []:
→ユーザのメールアドレス(admin@free-style.biz)を入力します。

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
→そのままEnterキー
An optional company name []:
→フレンドリ名(admin)を入力します。(各自お好みで)

---

「Netscape用」と言われていますが、クライアントで使用するために署名リクエスト(公開鍵)にCAの認証を付加します。
# cd /etc/pki/tls/misc
# openssl ca -out /usr/local/ssl/admin.free-style.biz.crt -infiles /usr/local/ssl/admin.free-style.biz.pem

---

Using configuration from /etc/pki/tls/openssl.cnf
Enter pass phrase for ../../CA/private/cakey.pem:
→CAの秘密鍵のパスフレーズを入力します。
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 6 (0x6)
Validity
Not Before: Jul 9 06:40:46 2010 GMT
Not After : Jul 8 06:40:46 2020 GMT
Subject:
countryName = JP
stateOrProvinceName = Tokyo
organizationName = Fs DataCenter CA
commonName = admin
emailAddress = admin@free-style.biz
X509v3 extensions:
X509v3 Basic Constraints:
CA:TRUE
Netscape Cert Type:
SSL Client, SSL Server, S/MIME, Object Signing
X509v3 Subject Key Identifier:
D6:4C:45:72:6E:17:9B:94:8F:C4:C1:8A:C0:43:69:59:4B:E5:A6:87
X509v3 Authority Key Identifier:
keyid:AF:3D:E9:BC:17:83:29:D7:C0:4D:3F:E0:32:51:2C:BF:B1:B4:0A:00

Certificate is to be certified until Jul 8 06:40:46 2020 GMT (3652 days)
Sign the certificate? [y/n]:
→「証明書に署名しますか？」と聞かれるので、素直に「y」

1 out of 1 certificate requests certified, commit? [y/n]
→「署名リクエストを作成しますか？」と聞かれるので、素直に「y」

Write out database with 1 new entries
Data Base Updated

---

クライアントに組み込むためにp12形式のファイルを作成します。
-export　→　クライアントの署名リクエストファイル名
-inkey　→　クライアントの秘密鍵ファイル名
-certfile　→　CAの公開鍵ファイル名
-name　→　フレンドリ名
-caname　→　ルートCA(サーバ証明書のホスト名)
-out　→　p12形式の出力ファイル名
# openssl pkcs12 -export -in /usr/local/ssl/admin.free-style.biz.crt -inkey /usr/local/ssl/client.private.pem -certfile /etc/pki/CA/cacert.pem -name admin -caname ca1.free-style.biz -out /usr/local/ssl/admin.free-style.biz.p12

---

Enter Export Password:
→バックアップ用パスワードを入力します。クライアントへのインストール時に必要になります。
Verifying - Enter Export Password:
→もう一度バックアップ用パスワードを入力します。

---

これでクライアント証明書の完成です。先に作成した「サーバ証明書」と今回の「クライアント証明書」の２つをクライアントにインストールすれば、おれおれS/MIMEが使用できるようになります。

以下、参考にしたサイト。CAを作成しないパターンや古い情報もあるので注意！

S/MIMEでセキュアなメール送信 in PHP

S/MIME(Secure MIME)で電子メールを交換する個人証明書作成を試す

CentOS5.3でオレオレCA局+SSL認証の作り方

SSLおれおれ証明書とクライアント認証

おれおれCA（プライベート認証局）が構築できたところで、「サーバ証明書」を作成していきます。いわゆる「ルート証明書」に当たるものです。

サーバ証明書の作成は、秘密鍵を作って、署名リクエストを作成して、CAに認証させるという手順を踏むのですが、CAを新しく作る手順の場合は、このCA作成のなかでほとんどの手順が終了してしまっています。

それではできている公開鍵が認証できるかどうか確認してみましょう。
# openssl verify /etc/pki/CA/cacert.pem

---

cacert.pem: /C=JP/ST=Tokyo/L=Shinagawa-ku/O=Fs DataCenter CA/CN=ca1.free-style.biz
error 18 at 0 depth lookup:self signed certificate
OK

---

SSL証明書用のユーザディレクトリを作成して、移動します。
# mkdir /usr/local/ssl
# cd /usr/local/ssl

クライアントに組み込むためのサーバ証明書を作成します。
# openssl x509 -inform pem -in /etc/pki/CA/cacert.pem -out ca1.free-style.biz.crt -outform der

これで終わりです。

というのもあんまりですので、別に証明書を作成して署名してみましょう。

証明書はユーザディレクトリに作成します。
# cd /usr/local/ssl

新しく秘密鍵を2048bitで生成します。
# openssl genrsa -out private.pem 2048

---

Generating RSA private key, 2048 bit long modulus
..+++
..........................+++
e is 65537 (0x10001)

---

秘密鍵を使用して署名リクエスト(公開鍵)を作成します。
# openssl req -new -key private.pem -out request.pem

---

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) [JP]:
→そのままEnterキー
State or Province Name (full name) [Tokyo]:
→そのままEnterキー
Locality Name (eg, city) [Shinagawa-ku]:
→そのままEnterキー
Organization Name (eg, company) [Fs DataCenter CA]:
→そのままEnterキー
Organizational Unit Name (eg, section) []:
→そのままEnterキー
Common Name (eg, your name or your server's hostname) []:
→ホスト名(ca1.free-style.biz)を入力します。(各自お好みで)
Email Address []:
→そのままEnterキー

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
→そのままEnterキー
An optional company name []:
→フレンドリ名(Fs DataCenter CA)を入力します。(各自お好みで)

---

「Netscape用」と言われていますが、クライアント用に必要なCA認証付きの署名リクエストを作成します。

作成はCAフォルダで実行します。
# cd /etc/pki/tls/misc
# openssl ca -policy policy_anything -out /usr/local/ssl/cert-ca.pem -infiles /usr/local/ssl/request.pem

---

Using configuration from /etc/pki/tls/openssl.cnf
Enter pass phrase for ../../CA/private/cakey.pem:
→CAの秘密鍵のパスフレーズを入力します。
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 5 (0x5)
Validity
Not Before: Jul 9 06:29:55 2010 GMT
Not After : Jul 8 06:29:55 2020 GMT
Subject:
countryName = JP
stateOrProvinceName = Tokyo
localityName = Shinagawa-ku
organizationName = Fs DataCenter CA
commonName = ca1.free-style.biz
X509v3 extensions:
X509v3 Basic Constraints:
CA:TRUE
Netscape Cert Type:
SSL Client, SSL Server, S/MIME, Object Signing
X509v3 Subject Key Identifier:
27:9F:05:BB:21:DC:E7:3A:86:04:22:04:70:B2:28:07:6B:66:19:00
X509v3 Authority Key Identifier:
keyid:AF:3D:E9:BC:17:83:29:D7:C0:4D:3F:E0:32:51:2C:BF:B1:B4:0A:00

Certificate is to be certified until Jul 8 06:29:55 2020 GMT (3652 days)
Sign the certificate? [y/n]:
→「証明書に署名しますか？」と聞かれるので、素直に「y」

1 out of 1 certificate requests certified, commit? [y/n]
→「署名リクエストを作成しますか？」と聞かれるのに、ここも素直に「y」
Write out database with 1 new entries
Data Base Updated

---

正常にサーバ証明書が作成されたか確認します。
CAの公開鍵と作成したサーバ証明書の指定はフルパスが確実です。
# openssl verify -CAfile /etc/pki/CA/cacert.pem /usr/local/ssl/cert-ca.pem
「/usr/local/ssl/cert-ca.pem: OK」と表示されれば正常に作成されています。

CA(認証局)の定義ファイルだけ作成して、おれおれCAを作成する方法もあるようですが、今回はローカルのデフォルトCAを入れ替える方法で作成します。

OS：CentOS5.3

1.オリジナルCAの定義ファイルをバックアップします。
# cd /etc/pki/tls
# cp -a openssl.cnf openssl.cnf.org

2.定義ファイルをおれおれCA用に変更します。
# vi openssl.cnf

---

#
# OpenSSL example configuration file.
# This is mostly being used for generation of certificate requests.
#

# This definition stops the following lines choking if HOME isn't
# defined.
HOME = .
RANDFILE = $ENV::HOME/.rnd

# Uncomment out to enable OpenSSL configuration see config(3)
# openssl_conf = openssl_init

# To use this configuration file with the "-extfile" option of the
# "openssl x509" utility, name here the section containing the
# X.509v3 extensions to use:
# extensions =
# (Alternatively, use a configuration file that has only
# X.509v3 extensions in its main [= default] section.)

[openssl_init]
# Extra OBJECT IDENTIFIER info:
oid_section = new_oids
alg_section = algs

[ new_oids ]

# We can add new OIDs in here for use by any config aware application
# Add a simple OID like this:
# shortname=Long Object Identifier Name, 1.2.3.4
# Or use config file substitution like this:
# testoid2=OID2 LONG NAME, ${testoid1}.5.6, OTHER OID

[ algs ]
# Algorithm configuration options. Currently just fips_mode
fips_mode = no

####################################################################
[ ca ]
default_ca = CA_default # The default ca section

####################################################################
[ CA_default ]

dir = ../../CA # Where everything is kept
certs = $dir/certs # Where the issued certs are kept
crl_dir = $dir/crl # Where the issued crl are kept
database = $dir/index.txt # database index file.
#unique_subject = no # Set to 'no' to allow creation of
# several ctificates with same subject.
new_certs_dir = $dir/newcerts # default place for new certs.

certificate = $dir/cacert.pem # The CA certificate
serial = $dir/serial # The current serial number
crlnumber = $dir/crlnumber # the current crl number
# must be commented out to leave a V1 CRL
crl = $dir/crl.pem # The current CRL
private_key = $dir/private/cakey.pem# The private key
RANDFILE = $dir/private/.rand # private random number file

x509_extensions = usr_cert # The extentions to add to the cert

# Comment out the following two lines for the "traditional"
# (and highly broken) format.
name_opt = ca_default # Subject Name options
cert_opt = ca_default # Certificate field options

# Extension copying option: use with caution.
# copy_extensions = copy

# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs
# so this is commented out by default to leave a V1 CRL.
# crlnumber must also be commented out to leave a V1 CRL.
# crl_extensions = crl_ext

default_days = 365 # how long to certify for
→クライアント証明書の標準の有効期間を「3652」日(10年)に変更します。

default_crl_days= 30 # how long before next CRL
default_md = sha1 # which md to use.
preserve = no # keep passed DN ordering

# A few difference way of specifying how similar the request should look
# For type CA, the listed attributes must be the same, and the optional
# and supplied fields are just that :-)
policy = policy_match

# For the CA policy
[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional

# For the 'anything' policy
# At this point in time, you must list all acceptable 'object'
# types.
[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional

####################################################################
[ req ]
default_bits = 1024
→標準の公開鍵長を「2048」bitに変更します。

default_md = sha1
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
attributes = req_attributes
x509_extensions = v3_ca # The extentions to add to the self signed cert

# Passwords for private keys if not present they will be prompted for
# input_password = secret
# output_password = secret

# This sets a mask for permitted string types. There are several options.
# default: PrintableString, T61String, BMPString.
# pkix : PrintableString, BMPString.
# utf8only: only UTF8Strings.
# nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings).
# MASK:XXXX a literal mask value.
# WARNING: current versions of Netscape crash on BMPStrings or UTF8Strings
# so use this option with caution!
# we use PrintableString+UTF8String mask so if pure ASCII texts are used
# the resulting certificates are compatible with Netscape
string_mask = MASK:0x2002

# req_extensions = v3_req # The extensions to add to a certificate request

[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = GB
→標準の国名を「JP」に変更します。

countryName_min = 2
countryName_max = 2

stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Berkshire
→標準の都道府県名を「Tokyo」に変更します。(各自お好みで)

localityName = Locality Name (eg, city)
localityName_default = Newbury
→標準の都市名を「Shinagawa-ku」に変更します。(各自お好みで)

0.organizationName = Organization Name (eg, company)
0.organizationName_default = My Company Ltd
→標準の組織名を「Fs DataCenter CA」に変更します。(各自お好みで)

# we can do this but it is not needed normally :-)
#1.organizationName = Second Organization Name (eg, company)
#1.organizationName_default = World Wide Web Pty Ltd

organizationalUnitName = Organizational Unit Name (eg, section)
#organizationalUnitName_default =

commonName = Common Name (eg, your name or your server\'s hostname)
commonName_max = 64

emailAddress = Email Address
emailAddress_max = 64

# SET-ex3 = SET extension number 3

[ req_attributes ]
challengePassword = A challenge password
challengePassword_min = 4
challengePassword_max = 20

unstructuredName = An optional company name

[ usr_cert ]

# These extensions are added when 'ca' signs a request.

# This goes against PKIX guidelines but some CAs do it and some software
# requires this to avoid interpreting an end user certificate as a CA.

basicConstraints=CA:FALSE
→サーバ証明を「CA:TRUE」に変更します。

# Here are some examples of the usage of nsCertType. If it is omitted
# the certificate can be used for anything *except* object signing.

# This is OK for an SSL server.
# nsCertType = server

# For an object signing certificate this would be used.
# nsCertType = objsign

# For normal client use this is typical
# nsCertType = client, email

# and for everything including object signing:
# nsCertType = client, email, objsign
nsCertType = server, client, email, objsign
→サーバ証明の種類を追加します。「SSL サーバー認証」「SSL クライアント認証」「SMIME」「 署名」とりあえず全部入れます。

# This is typical in keyUsage for a client certificate.
# keyUsage = nonRepudiation, digitalSignature, keyEncipherment

# This will be displayed in Netscape's comment listbox.
#nsComment = "OpenSSL Generated Certificate"
→コメントアウトします。

# PKIX recommendations harmless if included in all certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer

# This stuff is for subjectAltName and issuerAltname.
# Import the email address.
# subjectAltName=email:copy
# An alternative to produce certificates that aren't
# deprecated according to PKIX.
# subjectAltName=email:move

# Copy subject details
# issuerAltName=issuer:copy

#nsCaRevocationUrl = http://www.domain.dom/ca-crl.pem
#nsBaseUrl
#nsRevocationUrl
#nsRenewalUrl
#nsCaPolicyUrl
#nsSslServerName

[ v3_req ]

# Extensions to add to a certificate request

basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment

[ v3_ca ]

# Extensions for a typical CA

# PKIX recommendation.

subjectKeyIdentifier=hash

authorityKeyIdentifier=keyid:always,issuer:always

# This is what PKIX recommends but some broken software chokes on critical
# extensions.
#basicConstraints = critical,CA:true
# So we do this instead.
basicConstraints = CA:true

# Key usage: this is typical for a CA certificate. However since it will
# prevent it being used as an test self-signed certificate it is best
# left out by default.
# keyUsage = cRLSign, keyCertSign

# Some might want this also
nsCertType = sslCA, emailCA
→コメントアウトを外します。

# Include email address in subject alt name: another PKIX recommendation
# subjectAltName=email:copy
# Copy issuer details
# issuerAltName=issuer:copy

# DER hex encoding of an extension: beware experts only!
# obj=DER:02:03
# Where 'obj' is a standard or added object
# You can even override a supported extension:
# basicConstraints= critical, DER:30:03:01:01:FF

[ crl_ext ]

# CRL extensions.
# Only issuerAltName and authorityKeyIdentifier make any sense in a CRL.

# issuerAltName=issuer:copy
authorityKeyIdentifier=keyid:always,issuer:always

[ proxy_cert_ext ]
# These extensions should be added when creating a proxy certificate

# This goes against PKIX guidelines but some CAs do it and some software
# requires this to avoid interpreting an end user certificate as a CA.

basicConstraints=CA:FALSE

# Here are some examples of the usage of nsCertType. If it is omitted
# the certificate can be used for anything *except* object signing.

# This is OK for an SSL server.
# nsCertType = server

# For an object signing certificate this would be used.
# nsCertType = objsign

# For normal client use this is typical
# nsCertType = client, email

# and for everything including object signing:
# nsCertType = client, email, objsign

# This is typical in keyUsage for a client certificate.
# keyUsage = nonRepudiation, digitalSignature, keyEncipherment

# This will be displayed in Netscape's comment listbox.
nsComment = "OpenSSL Generated Certificate"

# PKIX recommendations harmless if included in all certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always

# This stuff is for subjectAltName and issuerAltname.
# Import the email address.
# subjectAltName=email:copy
# An alternative to produce certificates that aren't
# deprecated according to PKIX.
# subjectAltName=email:move

# Copy subject details
# issuerAltName=issuer:copy

#nsCaRevocationUrl = http://www.domain.dom/ca-crl.pem
#nsBaseUrl
#nsRevocationUrl
#nsRenewalUrl
#nsCaPolicyUrl
#nsSslServerName

# This really needs to be in place for it to be a proxy certificate.
proxyCertInfo=critical,language:id-ppl-anyLanguage,pathlen:3,policy:foo

---

定義ファイルを保存します。

この定義ファイルを基にして新しいCAを構築します。

念のためオリジナルCAをバックアップします。
# cd /etc/pki
# mv CA CA.org
# cd /etc/pki/tls/misc/
# cp -a CA CA.org

設定ファイルを変更します。
# vi CA

---

DAYS="-days 365" # 1 year
→ルート証明書の有効期限を「DAYS="-days 3652" # 10 years」(10年)に変更します。
CADAYS="-days 1095" # 3 years
→CAの有効期限を「CADAYS="-days 3652" # 10 years」(10年)に変更します。

---

新しいCAを作成します。
# ./CA -newca

---

CA certificate filename (or enter to create)
→そのままEnterキー

Making CA certificate ...
Generating a 2048 bit RSA private key
.....................+++
....+++
writing new private key to '../../CA/private/./cakey.pem'
Enter PEM pass phrase:
→秘密鍵のパスワードを入力します。
Verifying - 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) [JP]:
→そのままEnterキー
State or Province Name (full name) [Tokyo]:
→そのままEnterキー
Locality Name (eg, city) [Shinagawa-ku]:
→そのままEnterキー
Organization Name (eg, company) [Otwo Co Ltd]:
→そのままEnterキー
Organizational Unit Name (eg, section) []:
→そのままEnterキー
Common Name (eg, your name or your server's hostname) []:
→CAのホスト名「ca1.free-style.biz」を入力します。(各自お好みで)
Email Address []:
→そのままEnterキー

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
→そのままEnterキー
An optional company name []:
→そのままEnterキー
Using configuration from /etc/pki/tls/openssl.cnf
Enter pass phrase for ../../CA/private/./cakey.pem:
→最後に最初に入力した秘密鍵を入力します。
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 0 (0x0)
Validity
Not Before: Jul 9 01:59:38 2010 GMT
Not After : Jul 8 01:59:38 2020 GMT
Subject:
countryName = JP
stateOrProvinceName = Tokyo
organizationName = Fs DataCenter CA
commonName = ca1.free-style.biz
X509v3 extensions:
X509v3 Basic Constraints:
CA:TRUE
Netscape Cert Type:
SSL Client, SSL Server, S/MIME, Object Signing
X509v3 Subject Key Identifier:
AF:3D:E9:BC:17:83:29:D7:C0:4D:3F:E0:32:51:2C:BF:B1:B4:0A:00
X509v3 Authority Key Identifier:
keyid:AF:3D:E9:BC:17:83:29:D7:C0:4D:3F:E0:32:51:2C:BF:B1:B4:0A:00

Certificate is to be certified until Jul 8 01:59:38 2020 GMT (3652 days)

Write out database with 1 new entries
Data Base Updated

---

オリジナルCAが完成しました。

ちょうど仕事の案件でS/MIMEを使用することになったので、調べてみました。

私自身はMyDocomoで送られてくるこの画面・・・

でおなじみのサイバートラストのS/MIME証明書「Sure Mail」を当てにしていたものの、問い合わせてみると、

「この商品は電子署名のみで暗号化していません」

なんですとーーーー！！！

確かに、電子署名と暗号化が同時に適用されたメールは

このようになります。（後で調べた結果ですが）

勝手に電子署名と暗号化が適用されていると思っていた自分がバカでしたが、単なるフィッシング対策だけのために大仰な仕組みを採用しているとは思ってもみなかった。

他のSSL証明書発行会社ではクライアントで使用するS/MIME証明書しか発行しておらず、今回サーバーからプログラムで実行するという条件では使えないものばかり。

やはりメール暗号化はマイナーな存在だ・・・・

結局、自己証明書で実現するしかなさそうだ！おれおれCA構築するぞ！

5月に申し込んでいた吉野家WAONが先々週ようやく届いた。

そして今日の昼にWAONデビューしてきました！

「ワォン」

あれ！「ワォーーン」じゃないの？

大人の犬ではなく、子犬なのか？

というより吉野屋でチャージできないのが不便だな。

前回の続き

カスタムレポートで携帯の端末別に表示できたものの、「7」や「XP」などPCからアクセスした「OSのバージョン」がやはり邪魔ですね・・・

ということで方法を調査してみました。

まずは端末名リストの下にある「アドバンス フィルタ」を試してみました。

「OSのバージョン」に「XP」「Vista」「2000」を含まないとしてフィルタを適用します。

「7」は端末名にあるので外せませんが見れないことはありません。

ただ・・・・フィルタは１回限りということで、次回リンククリック時はリセットされてしまいます。毎回セットするのは・・・ダメですね。

ということで、前回作成したカスタムレポートを編集してみます。

気になるのは「ディメンション」の下の「サブディメンション」です。これどうやって使うんだろうか？

「OSのバージョン」を「サブディメンション」１階層目へ移動し、「モバイル」を「ディメンション」に、「月」を「サブディメンション」２階層目に、「週」を「サブディメンション」３階層目に、「日別」を「サブディメンション」４階層目にドラッグアンドドロップしました。

「レポートを保存」して表示すると・・・

最初の表示は「モバイル」かどうかのフラグ（「Yes」or「No」）になりました。

「Yes」（モバイル）のリンクをクリックすると・・・

「OSのバージョン」が表示されますが、上の階層でモバイルのみでフィルタがかかっていて希望通り！！ですね。

さらに、端末名のリンクをクリックすると端末別の「月」の集計数

「週」の集計数

「日別」の集計数と進みます。

「サブディメンション」は設定次第ではとても有意義な機能です。

最後に、一覧表形式ではなく、円グラフ形式にする方法を

表の右上に切り替え用のアイコンがあります。

通常は一番左になっていますが、左から２番目を選択すると、円グラフが見えます。

といっても、端末名が細分化しているので利用価値があるかどうかは別問題です。

大袈裟なテーマですが、今プスプスと火種ができている状態です。おそらく今年の年末頃になるとマスコミでも取り上げられる問題になる可能性もあります。

「暗号アルゴリズムにおける2010年問題」の対応により「公開鍵長が2048bit以上」になる(2011年以降は2048bit証明書のみ発行される)と、例えばベリサインの「セキュア・サーバID」のルート証明書は「VeriSign Class 3 Primary CA - G5」を使用します。

しかし、このルート証明書は最近の端末にしか搭載されていないため、旧端末を救済するための方法として、ベリサインでは「クロスルート方式」が採用されています。

実際のサイト証明書までの証明階層構造を見てみましょう。

「セキュア・サーバID」公開鍵長1024bit
Class 3 Public Primary CA - G2
　　Class 3 Secure Server 1024-bit CA - G2
　　　　サイト証明書

1024bitではルート証明書は「Class 3 Public Primary CA - G2」となり、サイト証明書との間に中間証明書が入る３階層となります。

「セキュア・サーバID」公開鍵長2048bit対応端末
Class 3 Public Primary CA - G5
　　Class 3 Secure Server CA - G3
　　　　サイト証明書

2048bitの対応端末ではルート証明書は「Class 3 Public Primary CA - G5」に変更となり、サイト証明書との間に中間証明書が入る３階層となります。

「セキュア・サーバID」公開鍵長2048bit未対応端末
Class 3 Public Primary CA
　　Class 3 Public Primary CA - G5
　　　　Class 3 Secure Server CA - G3
　　　　　　サイト証明書

2048bitのルート証明書「Class 3 Public Primary CA - G5」を搭載していない未対応端末では、最上位に「Class 3 Public Primary CA」を追加して４階層となります。「Class 3 Public Primary CA」はほとんどの旧端末に搭載されているので認証できることになります。これが「クロスルート方式」といわれる方法です。

しかし、携帯端末にルート証明書が搭載されていればOKかというと、話はそうは単純ではないのです。そもそも端末仕様として2048bit暗号を扱える端末（またはアプリケーション）なのかどうかが問題となるのです。

6月に入り問題となった、auのEZアプリ(BREW)向けサービスの一部の通信ができないという事象は、まさに2048bit暗号を扱えないアプリの問題でした。
https://www.verisign.co.jp/ssl/about/20100601.html

そのため、クロスルート方式であっても、今までのように旧端末もすべてカバーするとうわけには行きません。事実、2G機種や古いスマートフォン、一部の3G機種では対応できないことが発表されており、大幅に対応数が減っています。各社、3G機種のみを対象としたり、2006年以降発売の機種を調査の対象としていることは、その事実を隠そう！？としているようにも思えます。

2048bit未対応3G機種(ベリサイン)
https://www.verisign.co.jp/ssl/about/mobile_list.html

1024bit対応機種(セコムトラスト)
http://www.secomtrust.net/service/ninsyo/mobile_SSL.html

2048bit対応機種(セコムトラスト)
http://www.secomtrust.net/service/ninsyo/mobile_SSL_2.0.html

いろいろな情報を総合すると、2G以前の携帯端末はほぼ全滅ということになりますが、2013年以降はマイクロソフトがOSから1024bitのルート証明書を強制的に削除するという発表したこともあり、2、3年は混乱が続くものと思われます。

今3年以上の1024bit証明書をとってもPC対応は厳しく、かといって、2048bit証明書をとると携帯対応率が激減してしまうという、悩ましい選択を私たちは迫られています。

あなたはどう対応しますか？

SSL証明書の関係で、「暗号化アルゴリズムの2010年問題」という話題を先日書きました。それでは、今(2010年7月現在)携帯電話にはどんなルート証明書が載っているのだろうか？

ドコモ、au、ソフトバンクの３キャリアに搭載されているルート証明書を日本で購入する場合の正規発行会社別に上げてみた。

エントラストジャパン　http://japan.entrust.com/
Entrust.net Secure Server Certification Authority(Entrust Secure Server CA)
Entrust Root CA

サイバートラスト　https://www.cybertrust.ne.jp/index.html
Baltimore CyberTrust Root
GTE CyberTrust Global Root
CyberTrust Global Root

セコムトラストシステムズ　http://www.secomtrust.net/
Security Communication Root CA1
Security Communication RootCA2

コモドジャパン　http://www.comodojapan.com/
AAA Certificate Service
AddTrust External CA Root
COMODO Certification Authority

日本ベリサイン　https://www.verisign.co.jp/
VeriSign Class 3 Primary CA
VeriSign Class 3 Primary CA - G2
VeriSign Class 3 Primary CA - G3
VeriSign Class 3 Primary CA - G5
VeriSign Universal Root CA
(以下GeoTrustブランド)
Equifax Secure Certificate Authority
Equifax Secure eBusiness CA-1
GeoTrust Global CA
GeoTrust Universal CA

GMOグローバルサイン　http://jp.globalsign.com/
GlobalSign Root CA
GlobalSign Root CA-R1
GlobalSign Root CA-R2(GlobalSign)

RSAセキュリティ　http://japan.rsa.com/
RSA Secure Server Certification Authority
RSA Security 2048 V3
Valicert Class 3 Policy Validation Authority

ジェイサート　http://www.jcert.co.jp/
Starfield Technologies, Inc.
The Go Daddy Group, Inc.

メディックス　http://www.jp.thawte.com/
Thawte Premium Server CA
Thawte Server CA

全部で29個ありますが、auはLink to Link方式用に自社SSL証明書（KDDI SECURE NETWORK ROOT CA）を搭載しています。

これらはすべて使用されているわけではなく、将来のために搭載されているものもあります。つまり、暗号アルゴリズムが違うものだったりします。

ルート証明書というのは、SSL証明書毎に用意されているものかと思っていましたが、調べてみるとそうではありませんでした。

例えば、ベリサインでは、
「EV SSL証明書」でも「グローバル・サーバID」や「セキュア・サーバID」でも公開鍵長1024bit以下ではすべて「VeriSign Class 3 Primary CA - G2」を使用します。公開鍵長2048bitになると「VeriSign Class 3 Primary CA - G5」が使用されます。

ジオトラストでは、
公開鍵長1024bit以下では「Equifax Secure Certificate Authority」を使用し、2048bitでは「GeoTrust Global Root CA」を使用します。

コモドでは、
公開鍵長1024bit以下では「Equifax Secure Certificate Authority」を使用し、2048bitでは「COMODO Certification Authority」を使用します。1024bitまではジオトラストのルート証明書を借りて署名されていたため、携帯対応率が非常に高かったわけですが、2048bitになると自社ルート証明書に変更されるために対応率がかなり下がることになります。

今のところ調査していて1024bitと2048bitで同じルート証明書を使用するのは、セコムトラストの「Security Communication Root CA1」ぐらいですね。

Google Analytics(グーグル　アナリティクス) 携帯版を設定してみたものの「携帯端末」に表示されるのはキャリア名のみで、デバイス（端末）名が表示されないのはなぜ？？？って悩んでいました。

こういうデータです。（一部PC用OSが混ざってしまっていますが・・・実際の画面です）

手順を解説しているサイトは多数ありますが、どれも情報が古く、携帯版と言いながら機能変更でなくなったものと思っていました。

が！・・・

ようやく設定方法がわかりましたので、説明したいと思います。

まずは、左メニューの「カスタマイズ」メニューにある「カスタム レポート」をクリックします。

すると、このような画面（拡大可）が表示されますので、「カスタム レポートを新規作成」のリンクをクリックします。

レポートを自作できる画面（拡大可）になります。左メニューも何やら見慣れないものに変わります。よく見ると、メニューは昔のGoogle Analytics 携帯版メニューに近いようですね。

タイトルを編集できますので、「端末コード」とでも変更しましょう。

「ディメンション」の「システム」に「OSのバージョン」がありますので、それをドラッグして右のディメンションのところにドロップしましょう。

「指標」には「ユニークユーザー数」をドラッグ アンド ドロップしてタブ名を編集しておきます。

新規タブを追加すると、「ディメンション」はそのままですが、新しく「指標」を追加できます。「直帰率」を指定しておきます。

最後に下の「レポートを作成」ボタンを押すと・・・

デバイス（端末）名が表示されたレポートが追加されました。追加レポートは左メニューの「カスタム レポート」に追加されます。

しかし、WindowsOS名も混ざっていることから、標準メニューの「携帯端末」がデバイス名で表示されているほうがいいんですけどね。

「Wii スポーツ リゾート」以来一年ぶりにWiiのゲームを購入した。ということで、Wiiの電源が入るのも一年ぶりとなる。

「SDガンダム　ガシャポンウォーズ」

もう15年も前になるが、学生時代にゲームをやりつくした感があって、最近の綺麗なだけの長いゲームや小難しいだけのゲームはやる気がしなくなっている。

まずは「シナリオモード」からはじめてみる。ゲームの操作方法を教えてくれながらシナリオが進むモードだ。

戦闘はアクションゲームになっている。単純だが面白い。ゲームもさくさくと進むので久しぶりにハマってみようか。

今日、Wiiを最初に電源を入れたとき画面が映らなかった。原因は有線LAN用のアダプタ・・・。どうも調子が悪いらしく通信したり止まったり、ちょうど画面の切り替え時に通信が止まるとWiiが固まる。どうしようもないというより、システムアップデートでアダプタが不安定になっていないか？