先日Let's Encryptが正式版となったそうなので、本サイト及びモデラー向けサイトのSSL証明書を取得してみた際の備忘録。

• 参考サイトは日本語総合ポータルサイト
• 大体の手順は上記で問題なかったが、CentOS6ベースのサイトの場合、最初稼働させるまでに他サイトのお世話になった
  • ​Python2.7以上が必要らしく、そのインストールが標準yumだけではできなかったため。
• インストールしたクライアントが途中で80待ち受けを行うので、apache等のWebサーバが既に稼働している場合は一旦停止する必要がある。逆に言うと停止させれないサーバは何かしら考える必要がある。
  • 止めなくてもいい方法もある模様。かえってめんどくさそうだが。
• 取得コマンドのドメイン（てかホスト）指定オプション「-d」。複数指定することも可能なようなのだが、今回VirtualHostで同一IPのホスト名を２つ指定したところ、片方でDNS系エラーが発生し処理が止まった。１つずつコマンド処理したら大丈夫だったのでそれで対処。
• このように同一IPをネームベースVirtualHostしてる場合でも問題ない。まあapacheの設定は書き換えたが。詳細は他サイト参照。
• 取得する鍵にパスフレーズは含まれてない模様。そのまま登録→再起動で可。
• 鍵の有効期間は３ヶ月。ワリと頻繁に更新する必要があるなぁ。
• 気のせいか自作証明書よりSSL通信速度が速くなった気がする。

　この話、ネタにされやすいSSL関係だったり未対策サイトが多かったりでにわかに浮上してる感があるけど、

• 基本SSLv2を無効化するだけ＆最近のディストリはほとんど無効になっている
• 「対策してても秘密鍵を使いまわしてると無駄」というが、秘密鍵の使い回しって基本的にしなくね？（負荷分散サイトならともかく）
• 名称の付け方が流行りに乗ろうとしてね？
• 専用サイトの立ち上げ早くね？そしてチェックサイトがほぼ無意味（※その時チェックしてるわけじゃなくどうも巡回結果のDBぽい）じゃね？

　等々、なんとなく無理やり危険を煽ってる売名行為という印象も拭えない。
まずは冷静に、必要な対策を取ればよろしいのでは、と。

　身も蓋もない事言えばURLフィルタ系のツールでSSL対応を謳ってるものも似たような真似してるだろうしなぁ。基本的には「了解を得られれば」という話なんだろうけどもその「了解」がよくわからない方法で促されるし、仮に丁寧に説明してあったとしても一般の方は「ルート証明書？なにそれ交通費精算用？」みたいなことになりかねないしなぁ。

　もーこー言った話は義務教育に組み込んでもいいんじゃないかとすら思う…が世代間格差が広がるなぁ。

　最初リンク先の高木氏の話と矛盾してるよーに思えたので混乱しかけたが

1. 「httpsアクセスするところは漏洩を防ぐためにhttps限定にしhttpでアクセスできないように」と主張・指導するトコロがある。
2. その指導に従うと、httpsに対応したページはhttpをブロックしなきゃいけない。
3. 一般的にhttpでアクセスされるページにそれをすると困る（事がある）ので、仕方なくhttpsの方を封じた。

　とゆー流れの可能性があるのね。そうだとしたら本末転倒ですな。
　とりあえず「全てのページはhttpsであるべき」系の主張は一旦置いて、そらまあフォーム送信とかするページに手違いでhttpアクセスしちゃわれるとよろしくないからそのページはhttps限定にする、という発想はアリだと思うけども（※私もapacheの「SSLRequireSSL」使ってSSL限定ページを作ることあるし）、それを「http or https」という形式的な排他と判断するのはお役所的というか本質を外しているなぁ、と。

　リンク先の参照先にある各銀行の対応具合の統一っぷりを見ると、なんとなくお上系コンサルの指示に従ってるよーな気がするが、とは言え言ってる側は深い事考えずに「場所によってはhttps限定」って言いたいだけだと思うんだよね。言ってる側が言葉足らずなのか受け取る側が杓子定規なのか、はたまたその中間にいる人の翻訳ミスなのか。
　まあいずれにしても「全部httpsで」が実現すれば済む話ではあるけど、銀行とかはひょっとして「情報を閲覧できない可能性を排除しなければいけない→SSL非対応ブラウザの事も延々と考えなければいけない」とゆールールでもあったりするのだろうか。まあそれはそれで非対応端末がhttpsに来たらhttpに誘導すれば良い…って、つまり今回の方式になっちゃうのだろうか。

　Googleが開発？したhttps向け高速転送プロトコル「SPDY」。その存在は知ってたけどふとApacheの対応状況はどうなのと思って調べたところ、まだベータ版ながらもGoogleから「mod_spdy」が出ている事を確認。（更にApache Foundationに寄贈されたとの話なようなのでいずれ標準化も見込める）

　試しにインストール。ほぼそれで完了な簡単なお仕事。

　でもタイトル通り。これまでSSL限定にすべく「SSLRequireSSL」を設定していた箇所で403のPermission Errorが発生するようになってしまった。解決策らしきものは見つからなかったので取り急ぎ上記設定を解除。

　まあGoogleさんからすれば「世の中全てhttpsで」が主張なので特定箇所だけSSLを強制するこのディレクティブが無意味なのはわからないでもない。

　最近のGoogleはhttpsありきでクロールとかしているようで、https非対応のサイトはランクが下がるとかなんとか。取り急ぎ鍵の名前だけ実サイトに合わせたけれども自作鍵なんできっと意味はないんだよなぁ。世の中無料や低価格の証明書サービスもあるにはあるけどあまり使う気にはなれない。

　なのでこーいった形で標準化してくるのはきっとありがたい話ではあるのだろうけれども、標準化したらしたで仕組みの形骸化とか容易ゆえのセキュリティの甘さとか別の問題も出てくるんだろうなぁとかなんとか。

 

　ところでこの件で使ってるブラウザのSSL3.0通信を禁止してみたところ、けっこーな数のhttpsサイトにアクセスできなくなってた。思ったよりもあるようですな、古い環境。

　備忘。及び通知。

　　　ド　　　　ン


　「………………なん……だと……？」

　言ってみれば「来るべき時がキタ」的な印象。ベリサインがSymantecに買収されてから、特に表面的な、少なくとも一般利用者が明確にその事実を感じる場面はほとんど無かったよーに思うが、今回の変更は一版ユーザに対しても多少の影響があるよーに思う。
　まあ具体的には「え？俺ノートンなんか入れてないのになんで表示出てんだ？勝手にインストールされたのか？」といったレベルだとは思いますが（苦笑）。

　ところで参照記事中に「2010年にノートンがベリサインを買収」という記述がありますが（※本記事執筆時）「ノートン」は製品名（及び人名）であって会社名じゃないよね（苦笑）。まあうっかりスルーしそうではありますが。

　先日の偽SSL問題の渦中、というか発端となったDigiNotar。まあそりゃこれまで通りの運営は難しかっただろうけれども、にしても破産って対応を決定するには早かったんじゃないか？と。
　いや別に頑張って経営すればとかゆー話ではなく、これでは元々あんまり真面目に仕事しておらず面倒だからさっさと撤退した、とゆー印象を受ける。政府の認証基盤にも関わってたらしいのに。むしろ政府に関わった事事態が日本で言う所の天下りとかそれ系に基づくモノだったんじゃないの、と。

　ともかく今回引き起こされた騒動への対応としてはとてもお粗末だなぁと。

　むむむむ、人が忙しかったり腰を痛めて寝込んでいる間に（笑）こんな事が起きていたのか。結構面倒な事態になってるなぁ…。

　これまた厄介な。ここでいう「担当者のアカウント」って認証局の担当者？であればそこのセキュリティレベルはどーなってるのよって話だよな。

　最近お安さを売りにする孫ひ孫玄孫的なSSLベンダーをよく見かけるけども、何のかんの言って不安が残るのでベリサインにすることがほとんど。まーベリサインだから100%安全とゆー事ではないけれども、結局「サービスが一番良い所」なのは「一番お高い所」になると思うんだよね。

　話は変わるが今回の震災、一番最初にひたちなかへの配送を再開したのは比較的高めのヤマト運輸だった。普段のサービスレベルもヤマトが一番なよーに感じる。