Let’s Encrypt+NginxでWordPressをSSL化した時に起きたトラブル集

WordPress-Plugin
この投稿は最終更新から7年以上経過しているため、内容が古くなっている可能性があります。

サイトを常時SSL化しよう

SSL証明書が無料で使えるようになるという話は数年前に耳にしたことがあったのですが、いつの間にやら本格稼働していたので使ってみました。去年の話らしいですね、いつも気付くのが遅いんです。

そのサービス名は「Let’s Encrypt」といって、あっけないくらい簡単に証明書が手に入ります。
ドメインさえ持っていれば全てが無料で、コンソール上から取得&設置が完結できます。
有効期限は3ヶ月と短いのですが、更新は自動化できて無料なので実質無制限で問題はありません。

また、操作が良く考えられており、使用者は全員同じ作業で同じ階層に証明書を保管することになるので、手順を紹介したブログなどがすんなりと読みやすくなるというメリットもあります。

そんなわけで下記を参考にSSL証明書を取得しました。

光の速さのWEBサーバー(nginx)をlet's encryptでSSL化及びHTTP/2化。ついでにセキュリティ評価をA+にする。 - Qiita
前回のおさらい インフラ さくらのVPS(v4) SSD 1G CentOS7.2 (OS) ミドルウェア nginx 1.8.0 php7.0-fpm (アプリケーション) MariaDB(SQL) 5.5....
Let's Encrypt で Nginx にSSLを設定する - Qiita
Let's Encrypt で取得したサーバ証明書を Nginxに設定するための手順。 確認した環境は次の通り。 OS: CentOS 7.2 Nginx 1.11 Let's Encrypt 導入の事前準備 証明書を取...

上が「Let’s Encrypt」を使って、下は「Let’s Encrypt」のクライアント「certbot」を使用しています。
私は下の方を主に参考にしましたが、どちらでも良いと思います。

手順通りにすればあっさりと「Congratulations!」になるでしょう。

ドメインはまとめて発行する

ここでの注意点は、証明書を取得するドメインです。
私のやらかしたミスは「mndangler.net」のみで証明書を発行してしまった事です。

このブログのアドレスは「mndangler.net」ですが、一応「www.mndangler.net」でも接続できます。
この2つはブラウザにとっては別のサイトと認識されてしまうらしく、SSL証明書がそれぞれに必要なんですね。

「www.mndangler.net」への接続は「mndangler.net」へリダイレクトしているので表示される事は無いのですが、それでも理屈の上では「www.~」の方はSSL証明書を持たない “悪意があるかもしれない信頼できないサイト” になってしまうわけです。

これに気が付いたのは、Googleのサーチコンソールにサイトを「https://」で登録し直して丸1日経った頃です。メールで「www.~」の方が証明書と一致してないよと伝えられました。当然、WordPressのサイトも管理画面も「https://」へ移行してしまった後だったので、やり直しは超面倒臭い事になりました。

今から挑戦する人にはできるだけ同じ目に遭って欲しくないです。
ではどうすればいいのか? なんと、どちらにも使える証明書が発行できるようです。

ドメインのン入力時に、2つのドメインの間を「,」で区切ってこう書くだけです。

www.mndangler.net,mndangler.net

こういう形式をSAN対応と言うそうです。
似たものにワイルドカードというものがあるのですが、この2つの違いは次のようになります。

「*.mndangler.net」で取得できるワイルドカードは「www.mndangler.net」でも「info.mndangler.net」でも「hogehoge.mndangler.net」でも、後から追加されたサブドメインに対しても使用できます。

一方、SANは名前が確定しているものだけに対して使えます。「Let’s Encrypt」はワイルドカード対応ではないため、確定しているドメインだけをSANで取得するというわけです。

TOPへ戻るボタンが表示されなくなった

「TOPへ戻る」系のプラグイン「WP To Top」が表示されなくなってしまいました。
デベロッパーツールで「Console」を見てみると、jQueryが正常な順番で読み込まれていないようです。

これはこのプラグインのせいではなく、「Head Cleaner」のキャッシュが原因でした。

長いこと「Head Cleaner」の設定を放置していたのでキャッシュが随分溜まっていました。
すでに使っていないヘッダーのリンクなども全て残ってしまっています。

「https://」化したということで、思い切って初期化(アンインストール)して設定を1から見直しました。結果的に、<head>部で有効な JavaScriptとか3分の1くらいに減ってスッキリしました。昔は怖くて余りいじりたくなかった「Head Cleaner」ですが、やっぱりたまには見直さないといけないですね。

「複数の JavaScript を結合する」にチェックを入れると上手く動作しなかったので外しつつ、こんな感じにしてみました。

ついでに「WP To Top」を画像に差し替える方法を残しておきます。
プラグインのアップデートで戻されないように、テーマのCSSで上書きしています。

style.css
/**** WP to Top メインCSSより下に来るのでimportantを使う ****/
/* widthとheightを取って画像を背景として使い、文字を0pxにして消した */
.wp-to-top {
	bottom: 0px !important;
	opacity: 0;
	width: 100px;
	height: 100px;
	font-size: 0px !important;
	line-height: 0px !important;
	padding: 0px !important;
	background: url(./images/totop.png) no-repeat top center !important;
}

現行の「WP To Top」はWebアイコンを使用しているので、画像を背景として使っています。「width」と「height」を指定して、「font-size」は0にして消してしまいます。メディアクエリでスマホなどに小さく表示したい場合は、下のように指定します。

@media screen and (max-width: 480px)
/* Back to Top */
.wp-to-top { background-size: contain !important; right: 0px !important; width: 15% !important; height: 9% !important;}

「background-size: contain;」が背景画像を「高さ」と「幅」に合わせてくれます。

SNS Count CacheがFacebookなどを合算してくれない

「http://」と「https://」は別サイトとして認識されるので、SSL化してしまうとカウント数が0に戻ってしまうわけですが、「SNS Count Cache」にはSSL化前と後のカウントをどちらも取得して合算してくれるという素敵な機能があります。しかし、これがどうも上手く動作してくれない。

FacebookとGoogle+が、「N/A」で取得できないというわけではなく「0」なんです。

検索を掛けてみると色々と対策は出てくるのですが、私に効果があったのはこちらです。

SNS Count Cacheプラグインでhttps化対策 - Qiita
SNS Count Cacheプラグインについて SNS Count Cacheプラグインは、SNS系ボタンを高速に表示させるためのプラグインです。 SNS Count Cacheプラグインをインストールすると、SNS系ボ...

「sns-count-cache.php」の1153行(ver 4.7.2)にある以下の3~9行目をコメントアウトします。

sns-count-cache.php
// Pocket and Google+, Linkedin are excluded from migration target because they are migrated automatically.
	$this->scheme_migration_exclude_keys = array(
		//self::REF_SHARE_POCKET,
		//self::REF_SHARE_GPLUS,
		//self::REF_SHARE_LINKEDIN,
		//self::REF_FOLLOW_TWITTER,
		//self::REF_FOLLOW_FACEBOOK,
		//self::REF_FOLLOW_PUSH7,
		//self::REF_FOLLOW_INSTAGRAM
	);

PHPを更新すると再びキャッシュが始まり、今度は正常に機能しました。
正直これでなぜ上手くいくのか良くわかりません。

プラグインの更新次第では直るかもしれませんし、またここをコメントアウトする必要があるかもしれません。というわけで対策だけして様子見です。

リンクのURLに「//」を使う

SSL化後にまず行うのが、リンクを「http://」から「https://」へ書き換える作業だと思います。
WordPressには「Search Regex」という便利なプラグインがあるので、投稿内や画像はサクッと置換できます。

続いて、テンプレート内のリンクは自分で調べて手作業で頑張って書き換え。
よし、終わったなと思ったらまだMIX状態。
「http://」と「https://」が混在している状況です。

ついでにリンクチェッカーからもエラーが届きました。
記事内で紹介している引用元のサイトが「https://」で接続できないというオチです。

こういった場合や、リンク先がどっちかわからないという場合は「a href=”//mndangler.net”」という風に、どちらも書いてしまわなければ勝手に都合良く判断してくれるそうです。これでやっとサイトに 保護された通信が付きました。

最後に

以上がSSL化時に起きたトラブルです。

1番きつかったのが証明書の再取得でした。SSL化してしまったサイトを一度戻さなければならず、しくじって管理画面に入れなくなり、オレオレ証明書を用意してなんとか復旧しました。再取得には「/etc/letsencrypt」を一旦削除して~と色々なブログで書かれていますが、フォルダ名を変えるなどして残しておいた方が良いと思います。

半日掛かりましたが、色々と見直すことができて良かったです。
また、少しは重くなるかなと思ったのですがむしろ表示が速くなった気がします。

このあたりは元の設定に何か難があったのだろうと推測しつつ、また様子見していこうと思います。