はじめに

私の現場の知識が2019年くらいで止まっているので、今はもっといい話があるかもしれません。
コメント欄でもっといい話があればぜひ教えてください。

SSL化のメリット

そもそも何でSSL化するの、と聞かれた時に製作者として答えていたのは以下の2つです。

Google ChromeやSafariなどのブラウザがSSLに対応していないサイトに対して警告を出すようになった
HTTP/2という新しい通信形式に対応しているのがSSLだけ

※すごくざっくりHTTP/2について説明するとウェブサイトの高速化手法の一つです

SSL化のデメリット

よく言われるデメリットとそれに対する個人的な意見を述べます。

サイトの表示が遅くなる
- HTTP通信と比較すると多くの通信コストがかかっているので遅い、と昔は言われていましたが、現代においてネットワークのコストよりもアプリケーション側でかかるコストの方が圧倒的に高いので気にする必要はありません。
お金がかかる
- 信頼のために多少のコスト（月額換算200円程度）を払えないなら、独自ウェブサイトの運営は厳しいと思います。

では、実際にWordPressでSSL化を行う作業を見ていきましょう

SSL証明書を取得する
サーバに証明書を適用する
WordPressの管理画面からサイトURLをhttps://から始まるURLに変更する

以上！おしまい！

という記事は世の中にすでにたくさんあるかと思いますので、上記の手法でSSL化できない時に使っていた手法を書こうと思います。

SSL化されない原因

上記手法で証明書を適用したときにそれでも証明書が適用されない原因は主に2つです。

サーバにSSL証明書が適用されていない
SSL通信をしていないリソースがある

1に関してはみなさんがお使いのサーバの設定なので省略します。「絶対問題ない！」と思えるまで頑張ってください。
確認方法としては適当なファイルtest.txtをドキュメントルートの直下に設置して、https付きのURLでアクセスして問題なくアクセスできているようであれば大丈夫だと思います。
PHPが動作しているか確認するのであればファイル名をtest.phpなどに変更して以下のような記述をしておくとさらに信頼度が増すと思います。

<?php
$a = 'test';
var_dump($a);

2に関してが本記事の本題です。
SSL化をする上で大事な仕様として、そのページの全てのリソースがHTTPSで通信されていることが前提としてあります。
リソースというのはCSS、Javascript、画像など外部から読み込むファイルのことを指しています。

よくある話として、「SSL化したけど、トップページだけSSL化されてないんだよね」というものがあります。
トップページは表示させたい項目が多く、特にFacebook・Twitter・instagramなど外部のSNSを表示させようとする場合は、それぞれのプラットフォームで提供されている画像やJavascriptを直接読み込むことが多いです。

SSL化の作業をしたときに、そちら外部リソースへの設定が反映されずに「このサイトは保護されていません」といった表示が残ってしまうことは現場でよく聞いた話でした。

実際にどうやって確認するか

一つ一つのページを真心込めて確認していると日が暮れてしまうので、ツールの力を使いましょう。
私がオススメするのはGoogle chromeのデベロッパーツールです。
https://developers.google.com/web/tools/chrome-devtools?hl=ja

まずはデベロッパーツールを開き、ネットワークタブを開きます。
※ここではhttps://ja.wordpress.org/のサイトを例に紹介します。

ソースの種類でAllを選択し、項目のあたりで右クリックをすると表示したい項目を選択できるようになるので、「scheme」にチェックを入れましょう。

参考画像

こうすると、今表示されているリソースがhttpsで通信されているかどうかがわかります。
紹介したサイトではありませんでしたが、リソースが原因でSSL化に失敗しているサイトではschemeがhttpになっているものが存在しますので、それをhttpsで通信させることができたら、SSL化は成功します。
ここまで原因を特定できればだいぶ楽になるかと思いますので、デバッグの際にぜひ試して見てください。

http://で始まるURLが記事の中に大量に存在する場合

このような場合は記事が少なければ手で書き換えてしまえばいいのですが、記事が何百、何千とあるとつらいのでこういった場合もツールの力を頼りましょう。

プログラマーよりの方であれば「mysqldumpして、中身をhttp://◯◯◯.comからhttps://◯◯◯.comに変えて、インサートすればいいんでしょ？」と思う方もいるかもしれません。
ほとんどのテーブルは問題ないのですが、wp_optionsテーブルのデータはシリアライズされているデータもあり、文字数まで一致していない場合、インサート後の値の取り出しに失敗します。

値の書き換えに利用していた2つのツールを紹介します。

1はブラウザから利用することができるため、レンタルサーバ利用者向けのツールです。使い終わったらすぐにサーバ上からは削除することをおすすめします。
2はsshして利用する方にオススメです。DBの書き換えだけでなく、プラグインのインストールやtransientの削除などWordPress関連で幅広く使えるツールなので、インストールしておいて損はないと思います。
Search Replaceコマンド

事例紹介

最後に私が最近遭遇したSSL化に失敗していた事例を紹介します。
この件はさくらのレンタルサーバで発生した事象でして、さくらのSSL化プラグインを利用して実施したけど、トップページだけがSSL化されない、という話でクライアントから依頼をいただいたものです。

前述したようにGoogle Chromeのデベロッパーツールで調べるとinstagramの画像読み込みに失敗していました。
プラグインの中のJavascriptを読むとWordPressのsiteurlがhttpsで始まるならhttpsで画像を読み込み、そうでなければhttpで画像を読むと記述されていました。
（プラグインはSmash Balloon Social Photo Feedでした。）

実際に管理画面から値を確認するとhttps://◯◯◯.jpとなっていました。

ただ、phpMyAdminから確認したところ、DBの中身はhttp://◯◯◯.jpとなっていました。

管理画面から更新しても修正ができなかったため、今回はphpMyAdminの管理画面から直接値を更新したところ、無事にトップページもSSL化されました。

この挙動から、おそらくさくらインターネットさんで開発しているSSL用のプラグインは表示用のHTMLができあがった後に、httpで始まる記述をhttpsに変換して表示させている、もしくはDBから値を取得する際にhttpをhttpsに変換してると思われます。
（実際に確認したわけではないですが、困っている人のために私の憶測を残しておきます）

最後に

こういったノウハウってあんまり見かけないな、と思ったので記事にしました。
昨今ではSSL化を5,000円で受けているような案件も見かけるので、すごい時代になったなぁと思いながら傍観しています。

Twitterでノウハウを残しておくことの重要性を知りつつ、やっていなかった自分の戒めとして書きました。
誰かの参考になれば幸いです。