wizaman's blog (legacy) 当ブログを完全にHTTPS化しました。
年末年始になると、時間があるからなのか、自分のサイトを振り返ることが多い気がします。そんなことで休日潰して良いのかとも思いますが。
さて、当ブログはWordPressを利用しています。ロリポップのレンタルサーバー（ライトプラン）上で構築し、なんだかんだで5年近く運用しています。VPSではない。基本的にかかる費用はレンタルサーバー代と独自ドメイン代のみとなり、比較的安価です。その上、アマゾンのアフィリエイト仕込んだ商品リンクによる収入で元が取れてます。些細な金額なので積極的には狙ってませんが。
ブログ開設当初とは状況が変わってきたことと、これまでの運用経験を振り返って、個人ブログとしてのWordPressとの付き合い方について、自分の考えを整理します。HTTPS対応をどうするか、という話も含みます。
あまり人に読ませる文章になっていませんが、よろしければどうぞ。
要点
話が長くなるので要点を先に。
- 個人ブログで何がしたいのか目的は明確か？
- 目的に対してWordPressという選択は妥当か？
- HTTPS対応はすべきか？気をつけるべきことは？
こんな感じの話をするのですが、まあまあ重たい内容だし、多少の知識を要求するので、特別な理由がなければ個人がWordPressをインストール型として運用するのはやめといた方が良いんじゃないかなぁ、と思いました。
WordPressは使いたいけど、サーバやWordPressバージョンの保守はしたくない・・・という人なら、ブログサービスとしてWordPress.comを使えばいいでしょうね。
自由にプラグインやテーマを追加できないとか、独自ドメインは有料、といった制限のあるサービスですが、インストール型の運用コストを考えると、個人ではこのぐらいのカジュアルさでほぼ十分なんじゃないかと思います。
WordPress採用の動機
やろうとすることが妥当なのか判断するためには、動機をはっきりしておく必要があります。
私はWordPressを利用する前から個人サイトを持っていました。2000年代初期の個人サイト/個人ブログブームに乗った形で、明確な目的意識があったわけではないです。「作るのが楽しいから」「交流するのが楽しいから」というだけ。ただ、色々なことをやろうとすると、それなりに頑張らないといけないことがわかってきて、モチベと時間が見合わないので、やることを選択していくようになります。
過去、いくらかのブログサービスを使いましたが、下記の理由でうんざりしていました。
- レガシーなシステムのままアップデートされず使いにくい
- 過去記事へのアクセシビリティが貧弱（カテゴリ/タグによるグループ化など）
- サービス終了すると移行コストが発生するしURLも変わる
- できるだけ特定のサービスに依存したくない
- 独自ドメインを持ちたい
- デザインがイマイチだが自分でHTML/CSS書くのも嫌
- ブラウザ間の差異を吸収するのは個人では無理がある
- スマホ向けにレスポンシブデザイン実装するのもめんどい
- 出力されるHTMLがダサい
<p>使わず<br />だらけになるとか<strong>ではなく<b>が使われがちとか（HTMLは構造を示してスタイルはCSSで定義すべき）
- 広告が邪魔
書き出してみたら思ったより多かった。それだけ不満だったんですね。
とにかく、自分で制御できないものをひどく嫌うようになりました。それまでいくらか利用した無料ホームページスペースに対しても、似たようなことを感じていました。そこで、多少のお金は出したほうが安心で快適だと考えるようになりました。
当時（2013年）、私は学生でした。Web系の技術に対する学習意欲もあり、WordPressは手頃な課題でした。大学のサークルなどで触ることはありましたが、個人で全部面倒を見るのは初めてだったかな。実際、ApacheやPHPの良い勉強になったと思います。まあでも、あれだけ時間を割けたのは学生だったからだよな、とも思います。学生のうちに手広く勉強していたことは割と役に立っていますので、時間があって勉強目的でチャレンジするのはアリです。
個人サイトを開設した当初の目的に「交流」もありましたが、その意味で掲示板やブログは役目を終え、TwitterなどのSNSに統合されました。時代の変化ですね。
基本的に個人サイトはWordPressに集約させることとし、最終的に旧サイトはすべてたたみました。残ったブログは**「情報発信」や「記録」**の媒体として役割を明確化していきます。WordPressをそのまま使うのでは執筆作業の負担が重かったため、記事内容をMarkdownで書けるようにするなど徐々に改善していきます。
現在では、情報発信するものとして下記を意識するところに落ち着いています。
- Web上でなかなか見つからない情報
- Web上で溢れている誤った情報を正す情報
- 自分の考えをまとめた文章
これらはSNSでは果たせない役割かな、と思っていますので、ブログは便利です。ただ、それだけの動機だと独自にWordPressを運用するのは割に合わないと思ってます。
どこまでコストを払えるか
ちょっとWordPressから離れますが、これまで様々な技術やサービスのトレンドの変遷を見てきて思うことがあります。
昨今、あらゆるコンテンツに要求される質がぐっと上がり、制作コストが跳ね上がっています。その上でさらに流行り廃りも激しく、速い変化に耐えられるかどうかも重要になってきたと思います。背景としてはスマホやSNSというでかいプラットフォームの浸透がでかいですね。プラットフォームになりたがっている有象無象の製品は淘汰され、勝ち残ったこれらプラットフォームへの対応・連携は前提となりました。
これだけ作るものが複雑になってくると、イチから作るのでは手に負えなくなります。そのため、抽象化・自動化による効率化を試みる技術・サービスがどんどん生み出されていきます。特にここ5年ぐらいの変化は目まぐるしいです。
例えば、サーバサイドでは、システムの本質以外（つまりインフラ）にかかるコストをカットしていきます。地道に物理サーバを管理するのをやめて、AWSやGCPなどのIaaSとしてのクラウドサービスに置き換えます。サーバ上に構築する動作環境も色々なアプローチで自動化・抽象化します（DockerとかVagrantとか）。Webフロントエンドはカオスを極めていて開発者の悲鳴を聞きます。このへんはもう技術要素が多過ぎて、専門外の私にはよくわからない世界。
個人でちょっとしたWebアプリを作る程度なら、GAEやHerokuなどのPaaSを使えばインフラ作業から解放されて楽ができます。そのPaaSの独自仕様に縛られますが（ロックイン）、目的に合わせて使い分けるものだと思います。
私が仕事としているゲーム開発であっても、クライアントサイドでゲームエンジンを利用するのは当たり前となりました。これはクロスプラットフォーム対応のコスト削減だけでなく、開発イテレーションの活発化やワークフロー改善のためのエディタ環境/拡張が充実していることが大きいです。
だいたいどの分野でも、イチから地道にプログラムを書く時代ではないです。何らかのフレームワークやツールを組み合わせるのが常套手段ですが、その知識を獲得するコストと、それが廃れても保守する将来のコストを考えると、ちょっと気が重いのも確かです。
WordPressなどのCMSもWebサイトを構築・拡張するのを助けるものですが、なんやかんやサーバ用意したり、CMS本体やプラグインやテーマのバージョンアップと保守作業を続けていくのはまあまあ手間のかかることです。
例えば、去年はJetpackの更新で内部エラーを起こしました。さらに、ブログ記事にしませんでしたが、「WP Social Bookmarking Light」が2.0.0でPHPの最小サポートバージョンを5.6に引き上げたので、PHPのアップグレードとそれに伴う修正作業が発生しました（該当プラグインは数日のうちに2.0.1をリリースして再びPHP 5.3対応に引き下げられました）。そして、「WordPress HTTPS」が久々のアップデートとして年末に4.9.1をリリースして、共有SSLで利用している管理画面のCSSファイルのURLマッピングがおかしくなりました。共有SSLやっぱ無理があるなー、と。ここからどうしようか考えながら、本記事を書き始めました。もっと古い話でも、うまく動作しなくなったシンタックスハイライトのプラグインを変更したり、細かな変更を加えてきています。
このような保守作業を継続していかなければいけませんが、これが本当に面白くない作業だと感じます。やっぱりやりたいことの本質ではないのでしょう。だから、動機はきちんとしておくべきです。これから述べるHTTPS対応の話も、ほとんどのブログ管理者は気にしたくないコストだと思います。
関連する話題を調べて見つけた上の記事がなかなかまとまっています。個人ブログとしてインストール型WordPressを運用するのはよく考えたほうがいいよ、という結論に同意です。文章を書きたいだけなら、それ以外のことを考えないで済む環境にしましょう。はてなブログやWordPress.comは良い選択肢だと思います。
ある程度は自分でコントロールしたい私にとって、VPSの自由さには魅力を感じるところですが、それ以上にサーバ保守したくないので、安いレンタルサーバ利用に留まっています。でも、Crowiとか使いたいんだよなぁ・・・ぐぬぬ。
HTTPSに対応するべきか
独自でWordPressを運用する場合、HTTPSに対応するかどうか、ということも考えねばならない時代になりました。
HTTPSとは、SSL/TLSによる暗号化通信の上でHTTP通信を行うプロトコルです。つまり、通信路上での盗聴や改ざんを防ぐことができます。逆に言えば、普通のHTTPでは通信の盗聴や改ざんを防げません。
例えば、Webサービスへのログインが必要なとき、たいていパスワードを入力しますが、HTTPでは通信路上にいる第三者が盗聴可能なので、パスワードが盗まれるリスクがあります。だから、アカウント情報や決済情報をやりとりするECサイトなどはHTTPSに対応するのが常識です（たまに対応してない中小企業を見かけるので困りますが）。安全な通信が確立されているかどうかはブラウザがアドレスバーで知らせてくれるので、意識高い人は確認する習慣になっているでしょう。
HTTPSで通信の安全が保証されるならば、**「すべてHTTPSに対応してしまった方が安心なんじゃないのか」**と考えることもできます。しかし、HTTPSを実現するための前提として、証明書を発行しなければいけないのですが、これがなかなか費用がかかるため、個人サイトでは気軽に使えるものではありませんでした。とはいえ、個人サイトでもWordPressへのログインなど、HTTPSを利用したい場面はあります。今時、静的HTML置くだけの阿部寛みたいなサイトなんてほぼないでしょう。
そこで共有SSLが使えます。共有SSLは独自ドメインを諦める代わりに、ワイルドカードの証明書が適用されたサブドメインを借りることで、SSLを使えるようにするものです。私もこれまでWordPressの管理画面では共有SSLを利用してきました。通常のページ閲覧には独自ドメインのHTTPを使います。管理画面がダサいURLになろうが、閲覧者には関係のないことです。
その場合、コメント投稿者の認証が課題となりますが、当ブログではJetpackコメントを採用してWordPress.com経由となるため、こちらでHTTPS化しなくても多分それなりに安全に認証できるようになっていると思います。
しかし、ドメインを気にする場合、共有SSLはかなり使い所を選ぶものです。また、独自ドメインとの併用を考えると、URLマッピングの問題など割と厄介です。これが2017年に状況が一変します。共有SSLは良い方法ではないので、駆逐されるでしょうね。
「すべてHTTPSにしたい」という時代の流れが実際にあります。完全HTTPSに移行した企業サイトが増えているのもそうですし、Google検索のランキングアルゴリズムでもHTTPSに対応したサイトかどうかを少しだけ考慮に入れています。
また、Google Chromeでは、HTTPページにおけるフォーム入力時に警告を出すようになりました。
ここまでくるとユーザに警戒されないためにも、HTTPS対応しておくのが推奨される時代になった、と言えるでしょう。
そして、このようなWebの完全HTTPS化を目指す流れの中で、ついに**「Let’s Encrypt」という自動かつ無料でSSL証明書を発行する仕組み**が整いました。
暗号化通信が目的ならば、無料で証明書を利用できます。しかも自動化されているので、上記のようなサービスであれば、設定を変えるだけですぐに独自SSLによるHTTPSが利用可能です。こんな素晴らしい時代が来るとは・・・。
しかし、それでもきちんとHTTPS対応するためには、もう少し準備が必要なのが実際です。
今後、HTTPS対応が前提となってくると思いますが、共有SSLはおそらく滅びるし滅びたほうがいいので、「Let’s Encrypt」による独自SSL対応が広まるでしょう。そして、これまで共有SSLを利用していた部分を置き換えるものでもなく、完全にHTTPSに移行すべき、となります。個人サイト管理者は初期の手間が増えることになりますが、仕方ない流れかなぁ。
ちなみに、SSL証明書は、ドメインの持ち主を証明して暗号化通信する、というのが最低限の機能であり、これが「Let’s Encrypt」の守備範囲です。フィッシングサイトにアクセスしたとき、その持ち主を証明されても、情報の送り先としては信用できません。偽物が偽物の証明をしているだけです。そのため、実在の組織を証明するための機能も証明書にはありますが、そこにはやはり高額な費用がかかることになります。個人サイトならともかく、ECサイトなんかはきちんとお金かけるべきですね。
HTTPS化する
HTTPで公開されたページと、HTTPSで公開されたページは、異なるURLとなりますので、異なるページとして解釈されます。普通しませんが、仕組み的に異なる内容を返すことはできます（だからこそ、HTTPからHTTPSに飛ばすことができる）。Google検索は同じコンテンツだと判定すればHTTPSの方を優先する仕組みになっています。
しかし、せっかくHTTPSに対応したコンテンツがあるというのに、HTTPでアクセス可能という状況では困ります。HTTPでアクセスしたときは、HTTPSのページに転送（リダイレクト）するのが普通ですし、今後はそれが求められると思います。
ページがHTTPSであっても、画像など外部参照でHTTPのコンテンツを含むと、その部分が安全でない、とブラウザに警告されることになります。既存のHTTPサイトをすべて完全にHTTPSに置き換える際のハードルはここになるでしょう。
また、ドメインレベルで次回アクセスから、ブラウザにHTTPSでのアクセスを優先させるHSTS（HTTP Strict Transport Security）という規格があります。これはブラウザ側でHSTS情報を保存していれば、ブラウザの判断でHTTPによるアクセスをスキップして、最初からHTTPSでアクセスしにいく強力な機能です。HTTPS対応してない状態で発動すると該当サイトに全くアクセスできなくなるリスクがあるので、既存サイトをHTTPS移行するときは最後に設定するのが良いでしょう。
上の記事が、HTTPからHTTPSへリダイレクトする方法や、HSTS対応の方法など、完全HTTPS化に関するひととおりの作業を丁寧にまとめてくれています。いやぁ、なかなか大変ですね。
また、上の記事でも触れられていますが、既存のHTTPサイトをHTTPSに移行する場合、URLが変わるために各SNSでシェアされたカウントが引き継げない、という問題を覚悟しなければいけません。これはそういうものだと割り切りましょう。
SNSでのシェアカウントを調査・保存し、それを表示する「SNS Count Cache」プラグインが、HTTP/HTTPSを同一ページとみなしてカウントを合計するオプションを持ちますが、これは強引というか悪手だと思います。各SNSが期待する利用方法を素直に採用すべきだと思います。余計な独自対応をすると、余計な保守作業がさらに増えます。
カウントのリセットは一度だけだと思えば、「いつやるか」というだけの話だと思います。やるなら早いほうがいいでしょうが、移行はやや大変なので慎重に。
他に参考にしたのは下記。
- ロリポップで運営のWordPressサイトを、httpからhttps（SSL化）に無料で移行しました | Swingin’ Thinkin’
- WordPressの.htaccessを編集する場合の注意 » INSPIRE TECH
滅多に更新しないんで忘れがちなんですが、ロリポップはWAFが有効になっているとWordPressの設定変更に失敗するので、一時的に外します。もしFTPSを利用するなら、FTPアクセス制限で現在の自分のIPアドレスを登録しないとダメなので、そこも注意。
HTTPコンテンツへのリンクは、HTTPSに置き換えるのではなくて、プロトコルを省略する形にしました。例えば、ブログトップへのリンクは//blog.wizaman.netのような感じになります。これで現在のプロトコルを引き継ぎます。HTTPSしか使う気はないですが、念のため。
リダイレクトはWordPressだけが対象ならプラグインで対応するのが楽だと思いますが、一応WordPress以外にも使っているので、私は真面目に.htaccessで対応しました。面倒ですが、余計なものを巻き込まないようにサブドメインごとに対応しています。WordPressの自動生成部分に書き込まないよう注意です。追加した内容は下記。
# HTTP -> HTTPS Redirect
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>
HSTS設定はなくてもいいやと思ったのと、下手に手を出さないほうがいいなと思ったので、何もしてません。
私の場合、ほぼ上記の情報でなんとかなりました。プラグインで唯一問題が起きたのはSharebarのFacebookボタンがうまく表示されなくなったことです。何故。だいぶ古かったようなので、各SNSボタンのコードを公式から取得し直しました。
- Twitter Publish
- いいね！ボタン - ソーシャルプラグイン
- はてなブックマークボタンの作成・設置について - はてなブックマーク
- +1 Button | Google+ Platform for Web | Google Developers
はてなブックマークは特に変化なかったです。Google+は捨てていい気もしましたが一応。
ただ、設定変更時にGoogle ChromeがERR_BLOCKED_BY_XSS_AUDITORエラーを出しました。
XSS対策のため、特定のコードを含む内容を送信した時にエラーとする機能のようです。理屈は分かるんですが、今回それでは困るので、Google Chrome以外のブラウザから設定しました。
というわけで、HTTPS化が完了しました。共有SSLだとプレビュー使えないとか制限ありましたが、快適な環境が整いました。
ただ、やっぱブログやりたいだけの人がやる作業ではないと思いますね。