VPS、PSGI、WebSocket、Nginx、Unicorn、MariaDBとかそのあたりをいろいろと勉強しつつ、コンテンツとしては人工知能とか機械学習、IoT、モバイルウェブ・ウェブアプリあたりを広く発信していこうかな～なんて適当な考えで、新プロジェクト「CVMU」をスタート。

現状、まだドメイン取得（実は2年以上前に取ってた）とSSL証明書取得＆HSTS preload申請、あとはひとまず「MCRN（mcrn.jp）」と同じレンタルサーバにホスティングまでしかやってない。

勢いでやって失敗しやすいので、まずは紙のノートに構想をラフ書きしつつ、ローカルの仮想環境（VirtualBox）でテスト構築していくつもり（いきなりVPS借りてｇｄｇｄやってると、無料期間すぎて無駄なお金もかかるし）。

一応、今のところ決まってる仕様（予定）のメモ。
VPS：さくらのVPS 2G（SSD）石狩リージョン
DB：MariaDB 10
Webサーバ：nginx
アプリケーションサーバ（Rails）：Unicorn＋rbenv＋Ruby 2.2
アプリケーションサーバ（Perl）：Perl 5.18＋PSGI（Starman）
　※MT6動作確認済み環境（http://www.movabletype.jp/documentation/mt6/installation/system.html）
CMS：Movable Type 6.2

2ドメイン目のSSL導入で「7 さくらのレンタルサーバでSSL通信を強制する | SSLそこからっすか！？」を見てたら、フォルダの切り方が


/home/ユーザー名/www/ <---> https://デフォルトドメイン/（変更不可）
/home/ユーザー名/www/ドメイン名A/ <---> https://ドメイン名A/
/home/ユーザー名/www/ドメイン名B/ <---> https://ドメイン名B/

みたいになってた。

…。
……。
………。

あーーーーーーーーー！そうすればよかったんだ！！
これなら.htaccessが他ドメインに影響することもないし、デフォルトドメイン（ユーザー名.sakura.ne.jp）はwww直下に.htaccess置いて（※）無効化できるし。

※：無効化のための最低限の設定（ホスト名判定でプライマリ独自ドメインへのリダイレクトor全アクセス拒否）だけ書くことで、他ドメインへの影響をなくす。
逆に全ドメインに影響させたい内容（「Header set X-UA-Compatible "IE=Edge"」等）を書いておく手も。

ということで、早速フォルダの移動・リネームを実施。

mcrn.jpとは別のドメインに2個目のラピッドSSLを導入。
今回はコントロールパネルから申し込んだので、さくら側で証明書設定までやってくれた。

…んだけど、途中でちょっとしたミスをしてしまい、手続き完了まで時間がかかってしまった。

ミス１．SNI SSLを有効にしてなかった
「6 さくらのレンタルサーバでSSLを導入する | SSLそこからっすか！？」によると、申し込んですぐにSNI SSLが有効にできるらしい。
前は自分でCSR送って、中間証明書入れて、証明書受け取ってセットして、それからONにしてたから気付かなかった。

ミス２．HSTSセットしてた
まだ証明書がないのに気が早すぎ。

ミス３．上位階層の.htaccessが誤って効いていた
これは別記事で詳しく。

今日、J-WESTの請求額が確定したってメールが来たので、確認しようと思ったら見慣れない画面が。
メールに記載されてるログインページのURLは
https://www2.mufgcard.com/inet/jrw/login.html
で、J-WEST会員専用って書いてある。SSL証明書はEV。

一方、前回ログインしたページ（「MUFG Card」か何かで検索して見つけた）は
https://www2.cr.mufg.jp/newsplus/
で、汎用っぽい感じ。SSL証明書はノーマル（OV？）で、しかもSHA-1署名（セキュリティが弱い）。

後者のほうはログイン時に追加の情報（電話番号か生年月日の一部）を入れないといけないし、わざわざセキュリティの弱いほうでログインする必要はないので、次から前者のほうでログインしよう。

ところで、前者のログインIDのところに「（半角英数）」って書いてあるけど、前にも書いたようにMUFGのログインIDはアンダースコア・ハイフン・ピリオド使用可能なので、間違ってる気がする。
まあ、問題なくログインできるからいいけど。

新ブログに移行する作業をしていて、サイトグローバルの404ページではなく、ブログの404ページに飛ばすように/blog以下の.htaccessを書き換え。

そして、テストしてみると無事カスタムエラーが表示された…んだけど、ふと気になってChromeのデベロッパーツールで見てみると、何故か301リダイレクトが走って、エラーページ自体は200で表示されてる。
いわゆるソフト404。これはまずい。

でも、よくありがちな

ErrorDocument 404 https://foo.example.com/404.html

のように絶対URLを指定していなかったので、不思議に思い、mod_rewriteベース（REQUEST_FILE判定）や、CGIエラーページも試してみたけど、前者はそもそも全く反応せず、後者はエラーCGI自体こそ404を返すものの、一旦301でリダイレクトされてる。

ただし、メインサイト（「https://mcrn.jp/」）のみ。
カテゴリが「約定期blog GS」なのに詐欺っぽいけど、「さくらのブログ」だと共有・SNI問わずSSL使えない（「sblo.mcrn.jp」はもちろん、「mcrn.sblo.jp」でもダメ）から仕方ない。
先日6にしたばかりのMovable Typeのほうに引っ越すなら別だけど。

・なんかhttpsに斜線が
最初、Chromeでアクセスしたらアドレスバーに赤斜線が入ってて、明らかに「ダメ！」っぽい感じ。
「古い暗号スイート」とか出てたからSSL証明書の問題かと思ったけど、実はそこじゃなくて「このページには安全でない他のリソースが含まれています」のほうが問題だった。
原因は、さくらのブログとデザインを揃えるために手抜きでCSSを参照したら、CSS内のurl()で参照してる画像が「http://～」で読み込んでいることだったので修正して、無事赤斜線じゃなくなった。
（画像利用がいろいろとアレなので、いずれその辺を根本的に直したい）

・それでも「古い暗号スイート」って出る。
ChromeはTLS1.2以上、かつ特定の安全とされる鍵交換・暗号化・メッセージ認証アルゴリズムじゃないと最新って見なしてくれない。
参考：Chromeで「接続は古い暗号化技術により暗号化されています」の表示条件 - あすのかぜ
さすがにこっちはどうしようもないかな。緑色の「鍵」が出てることだし、よしとしよう。
（緑色の「アドレスバー」ではない。それはEV証明書なので超高価だし審査も厳しい）

Googleが常時SSLを推進して、ショッピングや金融じゃないサイトも軒並みSSL化する中、「特に意味はないけどSSL化したい。でも、証明書高いなー…」って思ってて、満足度アンケートにも書いてたらついに安価なSSL証明書が登場！

さくらインターネット、年額1500円で利用できるドメイン認証SSL「ラピッドSSL」 -INTERNET Watch

ラピッドSSLを初めて設定する｜さくらインターネット公式サポートサイト

キャンペーンで1年間無料ということで、さっそく申し込み。
※この記事投稿時点では、まだ証明書発行されてないので、発行され次第続報を投稿予定。

レノボPCの人は今すぐチェックを！一部製品にSuperfishの大穴 : ギズモード・ジャパン

斜め読みしかしてないけど、要するに
・なんと、LenovoのPCにSuperfishというアドウェアがプリインストールされてた
・しかも、Superfishは自己認証局SSL証明書（オレオレ証明書）を勝手に発行してHTTPS通信まで覗き見できる
・さらに、SSL以外の証明書（コードサイニング？）も発行できるから、Superfishがハックされたら高い権限を持つ不正なコードを警告なしで実行できうる
・残念ながら実はすでにSuperfishはハックされている
ということみたい。

あれ、Lenovoって、Miixもそうだよね？持ってるんだけど…！？

ニュースで騒ぎになってるOpenSSLのHeartbeat拡張実装バグによる脆弱性問題。
サーバのメモリ抜き出せてログも残らず、下手すると暗号通信覗かれたりパスワードもっていかれたりするらしい。

具体的な流れとしては、Heartbeatリクエストに「このリクエストの長さは65500バイトだよ」って書いておいて、実際は1バイトしか中身がない状態で送ると、受け側は本来そのまま1バイトの中身を返すべきところ、受け取った中身のあるメモリ位置から65500バイト分読み込んで返してしまうから、外部に出すべきじゃないデータが65499バイト分流出してしまうというもの（数値は例）。

で、そもそもHeartbeatって何に使うの？というのが疑問になったので調べてみると、普段ログインとかで使ってるSSL（TLS）である（TCP用）TLS以外にDTLSというUDP用TLSがあって、それにおいて通信相手の生存確認とかPMTU（送信するデータグラムのサイズを決める）に使われてるらしい。
もちろん、TCP用TLSでも意味のある通信をすることなくセッションを維持しておけるし、何より通常の通信を邪魔することがないという点が便利とのこと。

最初に言っておくと、実用性皆無です。
たとえ趣味でちょっとだけ試すにしても、常用するならおとなしくVPS契約するかHeroku等使いましょう

○できること
・さくらのレンタルサーバ（スタンダード）上でRuby on Railsが「一応動作してるっぽく見せられる」
（いや、実際動作はするんだけど使い物にならないってだけ）

○制限
サーバはWEBrick（開発用）
ポートは9800（WebDAV）
セキュリティとか負荷とか無考慮、たぶんWEBrick立ち上げっぱなしだと怒られる（なので満足したら即終了）

（このへんからなげやり）

参考サイト

http://tmpz84.blogspot.jp/2011/07/rails-3.html
http://blog.tmtr.jp/2013/04/nodejs.html
http://server-domain.info/news/sakura-tcp-port-restrict.html