聞こえますか。

 「寒くないですか。」で書いた啼き声の件だが,再チャレンジしてみた。 結構聞こえていると思いませんか。音の方に集中しすぎて画像の方はひどい手ブレ。そこはご愛嬌,ご勘弁。どこにとまってるかわからないうちに,啼き止んでしまって,そのあとで聞こえてきたのはずいぶん遠くからになっていたので,とまり位置が変わったんだろう。

 茶の間の窓から,デジカメで撮った。遅い昼食を食べていたら,ものすごく近くで例のオーシンツクツクが聞こえたので。かの声を聞けるのも,今年はあとわずかだろう。

 今日は,天気も良くなって,風も穏やか。もっとも雲はかなり出ているが。

 今年の重陽の節句は10/05のようですな。今でも着せ綿の習わしが残っているところはあるのだろうか。日本も狭いが広いから,そういう地域もあるかもしれないな。古典で「おらぶ」なんて言葉が出てきたとき,うちの辺では子供のころには年寄りが使っていた記憶があったので,「へえ,一般的には古語なんだ」と驚いたが,風習でもそういう例はあるかもネ。

「都道府県型JPドメイン名」の新設の話。

 JPRSが26日付で「JPRSが、地域に根ざした新たなドメイン名空間「都道府県型JPドメイン名」の新設を決定」を発表した。昨日,INTERNET WATCHの記事TECH.ASCII.jpの記事/.の書き込みなんかを読んで,「へえ」と思い,JPRSのプレスリリース内に「なお、同時点でご登録いただいているドメイン名については、引き続きご利用いただくことが可能です。」の文言があるのを見て,「そりゃ当然だろう。でも,紛らわしい事態が発生するよなぁ」なんてことを考えていた。

 ところが,今朝RSSで更新をチェックしていたら,徳丸さんが日記に「都道府県型JPドメインがCookieに及ぼす影響の調査 」というのを書いておられて,どうも紛らわしいとかのレベルではないらしい。

 徳丸さんの日記の中に「高木浩光氏の日記で指摘された「cookieを利用できない」という欠陥」という文言があったので,高木さんのところも読みに行った。高木さんは「JPRSに対する都道府県型JPドメイン名新設に係る公開質問」というのを書いておられた。

 どっちを読んでも,私のレベルではよく理解できないが,ブラウザベンダーがしっかりした対応を早急に取ってくれることが望めないとすると,結構問題が起こりそうということらしい。

 該当DOMAINの価格があまりにも高いので,そんなに普及しないだろうということらしいけど,それは希望的観測で,悪用するものが利益を見込んで取得するということも考えられるネ。「都道府県型JPドメイン名」ということだから,取得者へのチェックは相当入るだろうが。

寒くないですか。

 寒くないですか。相変わらず調子のよくないo6asanです。いい天気なのに,ちっともすっきりしないです。気分が悪いので愚痴です(爆)。

 精神的にはどこも悪くないのですが,胃痛から腰痛・悪寒と来ています。全身に蕁麻疹だし。実はどこか精神的に問題があるのではないかという気もするのです。だいたい,心身の身の方に強く症状が現れる傾向がありまして,意識上ではさして感じていないのに,円形はげが出来たり,潰瘍が出来たりする方です。しかし,今回は流石に心当たりがないなぁ。

 やっぱり急に寒くなったからですかね。思っている以上に老化が進んでいるんかしらん(汗)。まぁ,ここにバカなことを書く元気があるってことは大したことはないのでしょうが……熱は,少しあるみたいです。久しぶりに風邪でしょうか。明日あたり本式に発熱するのかも知れません。症状がはっきりする前にかえって気分が悪いということが結構ありますよね。

 どこかで,オーシンツクツクとツクツクボウシの啼く声がします。ツクツクボウシといえばこの間啼き声をデジカメで録音してみようとしたんですが,ダメでした。難しいものですね。耳でははっきり聞こえているのに,うまく録れない。人の耳の性能というのは,素晴らしいんですね。

 画像はhttp://www.h2.dion.ne.jp/~pv0ngdn/MUSHI/zkussho.jpg さんのを拝借しました。

XREAのCatchAllについて。

 どうも,体調のすぐれない一週間だ。急に寒くなったせいなのかもしれないが,久しぶりに胃痛が激しかった。リタイアしてから,めったと痛むこともなかったのに……
 ピロリ菌の治療をしてからずいぶん経つので,もしかしたら彼らが復活しているのかもしれない。10月のいつもの通院でちょっと確認してみようと思う今日この頃だ。せっかく涼しくなって,食事もおいしくなってきたはずなのに,そう感じられないって損だよねぇ。

 りりさんからコメントが入ったので,返事を書いていたんだが,長くなってきたので別記事として書くことにした。書くことって,CatchAllの話くらいしかないが,他のレンタルサーバはどうなっているのかなと思っていた点でもあるので,立てておけばどこかから情報が得られる可能性もあるという期待で。ちと,さもしいかしらん。

 りりさんは,Xserverでのネットワーク(マルチサイト、複数サイト)の構築に手こずってられるらしい。WordPressの日本語Codexのネットワークの作成のサーバ要件のところには,

  • サブディレクトリ型サイト
    .htaccess ファイルを読み込めるサーバの mod_rewrite 機能を用いて動作します。
  • サブドメイン型サイト
    ワイルドカードサブドメインを用いて動作します。Apacheでこれを有効にし、DNSレコードにワイルドカードサブドメインを追加する必要があります。(設定方法は手順2を参照のこと)
    と書いてあって,手順2では,

    1. webサーバ(例としてはApacheだけしか上がっていないが)で
      httpd.conf fileか自分用のバーチャルホスト・エントリーで
           ServerAlias *.example.com
      を付け加えてワイルドカードを有効にせよ。
    2. DNSレコード設定でAレコードとして
           A *.example.com
      を付け加えてサブドメインでのランダム文字列を有効にせよ。

    が書いてある。

  • 注意として,
    1. サーバ側でワイルドカード設定済みのホストであれば、自分で行なうのはDNSレコードの追加のみです。
    2. 共有サーバは対応していないかもしれません。この機能を有効にする前に、自分のウェブホストを確認してください。

    と書いてあるんだが,この辺どうなんだろうか。

 Xserverのこの辺の説明を読んだところ,Xreaとの違いはCatchAllの機能がないことのようだ。XreaのCatchAll機能というのは,*.example.comにあったアクセスをすべてdefaults.example.comにまとめる機能で,ここに集まったアクセスをWordPresstが.haccessのrewriteディレクティブで各ユーザに割り振ってやっているようだ。Xreaのhttpd.conf やバーチャルホスト・エントリーがどうなっているかは,私には全然わからないのだが,共有サーバで単純にCodexに書いてやっているようなことだけしかしていなかったら,違反者の管理が大変だろうから,いろいろとこまごましたことがあるんだろう。
 ところで,CatchAll機能というのはメールサーバでは聞いたことあるけど,レンタルサーバのこの手の機能の呼び名としても一般的なんですか。ググってみても,他ではあんまり出てこないようですが。

 XserverのDNSレコードについてを読むと,*.xserver-sample.comのAレコードは設定できるようになっている。しかし,*はなんでもいいわけだから,ここにアクセスされたものをすべてWordPressがインストールされている/public_htmlにアクセスさせる必要があるが,これができないようだ。サブドメインの使い方を読むとそうなっている。ここで,サブドメインを設定するとそれ用のディレクトリが勝手にできてしまう。この点は,CatchAllの機能を使わない場合のXreaでも同じだが,Xserverの場合これをFTPで削除しても,CatchAll機能が使えないとだめなんだろうなぁ。できたサブドメイン用のディレクトリを全部削除し,下のデフォルトのDNS設定を*.xserver-sample.comのAレコード以外全部削除しても,機能してくれないかな。まぁ,その辺の設定は,安全を考えてきっちりやっているだろうから,無理かなという気もする。

     ホスト名 種別 内容 優先度
     xserver-sample.com A xxx.xxx.xxx.xxx  
     www.xserver-sample.com A xxx.xxx.xxx.xxx  
     xserver-sample.com MX xserver-sample.com 0
     *.xserver-sample.com A xxx.xxx.xxx.xxx  

マイクロソフト セキュリティ アドバイザリ (2607712)更新-#2。

 ちょっと,バタバタしていて出遅れたんですが,「DigiNotarが破産申立」なんていうのも出てました例の件,KB2616676にVer.2が出てます。

 これは,「マイクロソフト セキュリティ アドバイザリ (2607712)更新。」の追記(9/15)で書いた既知の問題関係なので,Windows XP および Windows Server 2003 ベースの方に関係します。マイクロソフト セキュリティ アドバイザリ (2607712)の「よく寄せられる質問」の「なぜこのアドバイザリは 2011年9月20日に更新されたのですか?」のところに書いてある通りです。

 自動更新で,順調に2607712―→2616676の順でパッチがあたった方は無問題。不安な方は,上記リンクからVer.2を落としてあてとけば,悩む必要がなくなるでしょう。

Redirection,入れました。

 サイトをWordPressにまとめたのに伴い,301や404エラーが出ている。
 Redirectionという,優れもののプラグインを入れてみた。日本語ブログの方は,旧/BLOG-J/を新/blog-j/に飛ばしてやる設定をしただけで,もうすっかりよくなって嬉しいんだが,英語ブログの方はMTからWPに替わってURLがずいぶん変わってるので,一気というのはちょっと無理そうだ。
 仕方ないので,結構404が出ているページだけ,ぼちぼち変えていってやることにした。

今年は,十六夜で。

 夕べは,中秋の名月でした。結構お月見できたところもあったようですが,今年の我が家からは無理でした。庭に出て,空を見上げてみたのですが,雲が厚く,満月の光は漏れていましたが,月影は望めませんでした。

 今夜は,十六夜(いざよい)。打って変わって見事な月夜。というわけで,庭からの写真は十六夜の姿になりました。お月さんの姿だけでは,去年との違いはわからないですが。

 中秋の十六夜とは時期の違う十六夜ですが,この言葉で頭に思い浮かぶのはやはり「十六夜日記」です。これを縦書きにしてみました。

デジタル証明書と認証局。

投稿アップデート情報  早速の追記(9/11)  追記2(9/13)

 前記事を読み直してみて,「だから何?」と自分が思ったので,別表題にて追記。

 「デジタル証明書と認証局」の基本については,下の2記事がわかりやすく感じたので,読んでみてください。掲載されたのが相当古いけど,基本の理解にはお役立ちだと思います。

  1. 電子証明書と認証局
  2. 電子証明書と認証局

1. のほうは全ページ読むには無料会員なってログインしないといけないですが,両方合わせて読めば,ログインしなくてもなんとなく雰囲気はわかると思います。

 ということで,我々一般ユーザとしてはどうやって対処すればいいのということになるのですが,シマンテックのセキュリティ関係のブログにこの4件があがっていました。しかし,この4件は今回の事件が無くても当然やるべきことだし。

  1. 最新のルート証明書を手に入れるために,ブラウザ(IEやFirefoxなど)をアップデートする。
  2. EV SSL証明書が導入されている場合は,ブラウザのアドレスバーが緑に変わるのでこれを確認。
  3. 公認のトラストマークを探して確認する。
  4. 安全な環境を表す“https”の’s’がついているのをページが変わるごとに確認する。

 2. と3. についてだけど,2. については,IE8から対応しているようだが,EV SSL証明書しているはずの「日本ベリサイン」でさえ,うちのはグリーンになってくれなかった。なんでか分らんけど。いつもはIE8をほとんど使わないので今日にいたるまで気づかなかったという体たらく(ハハッ)。Firefoxは,なった。右の図のアドレスバーのところを見てください。
 3. については,昨日書いたAmazonでは見つけ出せなかった。見つけ出せた方,教えてください。m(_”_)m
 昔は入り口で見たような気がするんだけど,大きいサイトだから今でもどっかにはあるんでしょうが。これだけの大会社になると企業の知名度だけで信用されるだろうから,実際の通信の安全性だけが確保されていればトラストマークの表示の有無は大勢に影響はないのでしょう。

 さっきも書きましたが,上記の4つは,1. のルート証明書で証明されている会社自体が信頼できないという今回のような事態が起こらなくてもやるべきことです。
 今回,G-Mailを利用している場合など,もしかしたらすでに情報を抜かれているのに気づいていないだけかもしれません。すでに受けた被害については自分で調べて警察に行くしかないでしょうが,今後受けないためには次のことをしましょうということらしいです。これは,TechCrunch Japanの翻訳記事からです。しかし,機械翻訳だろうか,すごい読みにくい記事。

  1. パスワードを変える。
  2. アカウントリカバリオプション(第2のメールアドレスや電話番号など)を確認,アップデートする。
  3. 自分のアカウントにアクセスさせているWebサイトやアプリケーションをチェックし,よく知らないものは解約する。
  4. 自分のGmail(他のメールでも同じ)の設定のうち,疑わしい転送アドレスや委任アカウントをチェックする。
  5. Webブラウザの画面に現れる警告メッセージに注意し,それらをうかつにクリックしないこと。

 対象は,もちろん,Gmailユーザなんだけども,他のウェブメールを使っている方にも役立つ手順だと思います。

 これで,いくらか補足になって言いたかったことが皆様に伝わるでしょうか。

早速の追記
 ここ2・3日,バタバタしてTwitterに行ってなかったんですが,今(13:00)行ったら,認証が消えてました。右の画像を見てください。これは,Firefox6.0.2の場合ですが,IE8ではまだ,前のと同じ認証メッセージが出ます。ブラウザごとに対応が違うんだ。そういう話は聞いてはいましたが,初体験です。しかし,Twitterのつぶやきを書くページは,アドレスバーの左端がいつも赤丸の状態だったかどうか記憶が定かでない。見てるようで見ていないもんです。

追記2(9/13):
Green Bar FirefoxのTwitterに緑が戻ってきました。認証局がVerisignになっています。
 Twitterの利用のときに私はいつもhttpsだけで利用しているのですが,上の青いTwitterアイコンだけの表示にちょっと違和感を感じたんです。しかし,どんな状態だったかというしっかりした記憶はなかった。でもやはり,ここはグリーンバーが正常なんですね。

Amazonのデジタル証明書の表示方法。

 一昨日書くつもりだった記事が,サイト移転に手間取ったせいで今日になってしまった。でも,書いておきたかった件なので,やはりアップしておこう。

 今回,DigiNotarの不正証明書発行による被害の話の関係で,仕事のときに個人情報保護のためにSSLで通信しようと私的デジタル証明書を作ったときのことを思い出した。

 私的というのは,公的機関の証明を受けていないということで,SSL通信の効果としては何も問題はない。もちろん,安全についての注意すべき点も,公的ものと同じだ。ただ,零細で斜陽の勤め先だったので,公的機関(例えば,VeriSignとか―こっちは今のところ問題は報告されていない―今回問題になったDigiNotarとか)で証明を受けるための予算を出してもらえなかった。使ってもらう相手先もだいたい決まっているので,使用開始の前にオフラインでお願いをすることにしていた。

 で,実際に相手先にお願いをする前に,同僚に使い勝手を試してもらったのだが,事前にかなり詳しく説明した(口頭でだった。これが問題だったかも。)にもかかわらず,明朝の報告で通信はできたが,私が言ったようなメッセージは出なかったといった人がひとりいた。実際に,仕事場で私が手順通りにやって見せ,警告画面ってこれのことだよと指摘すると,そういえばそんなのあったという話になった。

 私的証明書だと必ず警告が出るはずだが,それでも上記のように気づかない場合もある。しかもこんなのが出るよと口を酸っぱくして念押ししていてさえだ。無意識に,マウスで「はい」をクリックしていってしまうのだ。ブラウザによってメッセージの出方が違うのも問題だ。バージョン違いだけで様子が違うこともある。
 ましてや,WindowsUpdateなどで知らないうちにインストールされているルート証明書の場合だと,存在すら知らない人が結構多いだろう。
 今回,気をつけなさいと言われても何に気をつけるんだと困っている人も多いかもしれない。今どきだから,オンラインショッピングなどをすることは多いだろう。だから,実は,デジタル証明書のお世話になっているんだが,気づかずに使っているってことだ。

 というわけで,今日はデジタル証明書ってこんなものなんですよという話を,Amazon.co.jpを例にしようと思う。しかし,初めから問題があるんだ。さっき書いたようにブラウザごとに表示のしかたが違う。ブラウザ全種について説明するなんて不可能だから,「なんとかのツッパリ」にもならないかもしれない。まぁ,でもやらないよりはいいだろうという程度。他のブラウザの方は,頑張って自力でやってみてください。
 それから,ブラウザとしてはインターネット・エクスプローラの利用者が一番多いだろうからこれで行くが,我が家には,バージョン8しかないので,ご了承願う。

 前置きはこのくらいにして―相変わらず長いという突っ込みは無し!!―本題に入る。画像のアップの都合上横幅を狭くしているので,気をつけてほしい。

  1. http://www.amazon.co.jp/にアクセスすると,図1のようなページが表示される。(1)のところがhttp://になっていることを覚えておいてほしい。
  2. Amazonで買い物をするにはサインインをする必要がある。先に品物を選んで,後にサインインという人も多いだろうが,今回の場合は,すぐにサインインボタンを押してみよう。すでにAmazonのアカウントを持っている人は(2),初めての人は(3)をクリックする。実は,どちらをクリックしても現れるページは同じである。
  3. クリックすると,図2のように「セキュリティの警告」窓が現れる。過去のどこかの時点で,図2の赤丸の部分にチェックを入れてOKをクリックしたことがある人は,これが出ずに図3の画面になる。警告画面が出た人は,赤丸のところはチェックを入れないままにしておこう。そして,OKをクリックする。図3の画面になる。(4)のところがhttps://になり,(5)のところにカギマークが現れたことに注意。
  4. 次は,このカギマークをクリック。図4のように「Webサイトの認証」窓が現れる。ここでは,「VeriSign」という会社がwww.amazon.co.jpを認証している。(6)をクリックすると,Windows Internet Explolerのヘルプのページが現れ,ここにはサイトの信頼性を判断する方法が列記されていてとても大事なのだが,今回は信頼性のチェックではなく,証明書を表示してみるのが目的なので,(6)ではなく(7)をクリックする。
  5. パッと新しい窓が開く。これがデジタル証明。(図5)
  6. 「全般」「詳細」「証明のパス」とタブが3つある。各タブを押して内容をみてほしい。この証明書が通信を暗号化して安全を図り,そのおおもとの認証がVeriSignのものであることがわかる。
  7. これがあるからと言って絶対安全というわけではない。この記事の初めの方に書いたが,この種の証明書は私のような個人にも作れるのだ。ただ,その私的証明書の場合は,VeriSignのような会社の認証はついていない。親しい人とSSLを利用してより安全な通信をしたければそれでもかまわないが,Amazonのように不特定多数のお客様と取引したければ,どこか信用あるところに認証してもらう必要がある。それがこの場合,VeriSignなのだ。

 

 

 

 

 こう書けば,VeriSignと同種の会社であるDigiNotarが引き起こしたことが大変に困ったことで,しかもその規模がわからないということは,深刻な事態だということがわかる。各ブラウザのベンダーが,DigiNotarの証明書が使えないように,アップデートで素早く対応したことも納得できると思う。

追記(9/11): 次記事に書き足りないと感じたことを書きました。

本家のお世話-#10。(リンク切れ)

 昨日は,ほぼ12時間のサーバダウン,失礼いたしました。
 前もってご連絡のできないドジによるダウンで,WordPressのマルチサイトがらみでは2度目。今回はたぶんデータベースの処理のミスだと思うが,まあーったく困ったもんだ。メッ。—–>> 自分

 今朝,アクセス解析を見ていて気づいたが,我が家には日本語zipファイルを落としに来る方がいらっしゃる。その大事な目玉商品のリンクを直し忘れていた。orz
 大概気をつけたけど,リンク切れチェックをしていないので,まだどこかに「切れ」が残っているかもしれない。

 それから,動画関係がうまくいっていない。自鯖に動画専用サーバを建ててやっていた分はもちろんだが,ファイル用のディレクトリ(blog-j/files)に置いてある分についてもうまくいかない。それに動画用のタグがソースから消えているんだけど,これはなんでだろう。
 この間,りりさんにつきあってもらってサブドメインタイプのWordPressネットワークのマルチサイトを試したときも動画でいろいろと起きたが,今回も手を焼きそう。

 まぁ,昨日の今頃に比べると天国だけど……。昨日は本当に「どうしよう」と思ったよ。最悪,自鯖の電源を入れるという手は残っていたが(笑)。