格安でサイトをHTTPSに移行する方法のメモ【さくらのレンタルサーバスタンダード＋ Comodo PositiveSSL ＋ WordPress】

さくらインターネットの「さくらのレンタルサーバ」で独自SSL機能が追加されたので、WordPress で作成したサイトの HTTPS化を行ってみました。

さくらレンタルサーバのSSL仕様
日本語ドメインでのSSL化
格安SSL証明書の取得とインストール
WordPressのSSL化

これらの組み合わせは多少戸惑うポイントがあります。そこでメモとして記録を残します。

1. SNI SSL の検討

「さくらのレンタルサーバ」の独自SSL機能は以下の通りです。

独自ドメイン名ごとにSSLサーバ証明書を設定可能
「さくらのレンタルサーバスタンダード」はIPアドレスベースでなくネームベースの「SNI SSL」
「SNI SSL」では最大39ドメイン分のSSLサーバ証明書を設定可能
SSLサーバ証明書の持ち込み可

「SNI SSL」は SNI に対応していないブラウザで利用できません。

「SNI SSL」対応ブラウザ

【PC】

Internet Explorer: 7以降（Windows Vista以降）
Chrome: Windows Vista以降・Mac OS X 10.5.7 以降でChrome 5.0.342.1以降
Mozilla Firefox: 2.0以降
Safari: 2.0以降 (Windows Vista以降・Mac OS X 10.5.6 以降)
Opera: 8.0以降

【iOS】

Safari: 3.0 以降 (iOS 4.0以降)

【Android】

標準ブラウザ: Android 3.0 (Honeycomb) 以降

【ガラケー】

ほぼ未対応です。

気になるのは「SNI SSL」対応ブラウザです。
WindowsXP は MS のサポート終了して1年も経つので無視しても良いと思われます。
ガラケー未対応ですが、現時点(2015/5)でガラケーでWEBアクセスする需要があるとは思えませんし、そもそもHTTPS化するサイトがガラケー対応していません。
「SNI SSL」でまったく心配ないかというと不安もありますが、まず問題ないとしました。
HTTPS化するとGoogleの検索結果ランキングに、少しだけ有利になるといった利点もあるそうです。

2. SSL証明書の取得

さくらレンタルサーバスタンダードでのSSL設定方法は、さくらインターネットサポートページ「SSLを初めて設定する」に詳しく記載されています。

秘密鍵を2048ビットで生成し、CSRの生成を行います。
このCSRを使ってSSL証明書を取得します。

SSL証明書は、SSLストアさんから、Comodo PositiveSSL 1,200円(税込)のSSL証明書を取得しました。
当初最安値の KingSSL 900円(税別) のSSL証明書取得申請したのですが、『今回お申込みいただきましたコモンネーム（FQDN）では、フィッシング審査が必要となりました。自動審査を通過しなかった場合、コモンネームを変更して、再度お申込みいただくか、フィッシング審査の追加審査可能なアルファSSLをご検討下さい。』となり取得できませんでした。
アルファSSL は 6,000円(税別)～です。

後に分かったのですが、コモンネームが日本語のとき、セキュリティチェックにかかる確率が高いそうです(SSLストアサポートページによる)。
SSLストアの Comodo PositiveSSL は、認証局のセキュリティチェックにかかった場合は人的審査が行われます。
そのおかげか、KingSSL で自動審査を通過できなかった日本語コモンネームは、SSLストアの Comodo PositiveSSL では審査が通りました。
Comodo PositiveSSL では、通常30分以内に認証局のサーバからSSL証明書が自動発行されるそうですが、人的審査が行われたようで、約半日後SSL証明書が発行されました。
SSLストアさんは証明書発行から2週間以内なら返金や再発行可能なので安心です（CSR生成で失敗して再発行して貰いました）。

3. 証明書のインストール

SSL証明書を取得しましたら、サーバ証明書とサーバ証明書に対応した中間証明書をインストールします。
インストール方法はさくらインターネットサポートページ「SSLを初めて設定する」に詳しく記載されています。

しかし、『送信されたデータは、このサーバで利用できない証明書です』となり、インストールできません。
Comodo PositiveSSL はデュアルアクセス対応（コモンネームが「www.+ドメイン名」と、wwwが付かない、ドメイン名のみでのアクセスも有効）です。
さくらインターネットのサポート情報で『マルチドメイン証明書やワイルドカード証明書のような複数のドメインをカバーする証明書は利用できません』とありましたので、その為かと思いサポートに尋ねてみたところ、『デュアルアクセス対応の証明書については問題なくご利用いただけます』でした。

インストール出来なかった SSL証明書をサポートに調べてもらったところ、日本語のコモンネームだとコントロールパネルからのインストールでエラーとなり、インストールできない状態となっていたことが分かりました。
今回はさくらインターネットのサポートにSSL証明書をインストールしてもらい、https でアクセスできることを確認しました。
コントロールパネルは、日本語のコモンネームでもインストールできるよう改修を予定するそうです。

4. WordPressの設定

さくらのレンタルサーバー対応
WordPressの設定変更
内部リンクや画像の参照元の変更
ページチェック
外部サイト登録情報更新
HTTPSへのリダイレクト

a.さくらのレンタルサーバー対応

さくらのレンタルサーバーは RewriteRule して https接続すると、単純には .htaccess や PHP が https接続と認識できません。
WordPress は RewriteRule で書き換えを行いますので、さくらのレンタルサーバーにインストールした WordPress は、そのままでは SSL接続で不具合が生じます。
対処法は以下の通りです。
wp-config.php の、「/* 編集が必要なのはここまでです ! WordPress でブログをお楽しみください。 */」の前に以下を追記します。

if( isset($_SERVER['HTTP_X_SAKURA_FORWARDED_FOR']) ) {
    $_SERVER['HTTPS'] = 'on';
    $_ENV['HTTPS'] = 'on';
}

if( isset($_SERVER['HTTP_X_SAKURA_FORWARDED_FOR']) ) {

$_SERVER['HTTPS'] = 'on';

$_ENV['HTTPS'] = 'on';

}

さくらレンタルサーバーの共有SSLを使う

b.WordPressの設定変更

WordPressのURL出力の設定をHTTPSのアドレスに変更します。
設定 - 一般設定で
WordPress アドレス (URL)
サイトアドレス (URL)
を https://サイトアドレスに書き換えます。

c.内部リンクや画像の参照元の変更

http://サイトアドレスになっている内部リンクや画像の参照元を修正します。

プロトコル相対URLに置換しました(URLの中でプロトコルを指定せず、いきなり //サイトアドレスで記述する)。
プロトコル相対URLは読み込み元のページと同じプロトコルが利用されます。
つまり、そのページが http:// であれば http:// が、https:// であれば https:// が補完されます。
プロトコル相対URLを利用すると、http:// へ戻ることも容易です。

WordPress は内部リンクであっても http:// から始まるURLで保存する為、URLの変更は大変な作業です。
今回、「Search and Replace for WordPress Databases Script」を使って置き換えました。
「Search and Replace for WordPress Databases Script」はシリアライズされた情報を含めてDBの置換を行います。
しかし日本語は扱えないようで Punycode表記は置換してくれますが、日本語表記は置換しません。
30件ほど残った日本語表記は、DBをシリアライズされた情報はバイト数も含めて直接マニュアルで書き換えました。

d.ページチェック

全てのページでHTTPが混在していないかチェックします。
2件変更しました。

d-1.ヘッダー内「XFN」の記述の削除

&lt;link rel="profile" href="http://gmpg.org/xfn/11"&gt;

1	<link rel="profile" href="http://gmpg.org/xfn/11">

これは不要なので、テーマファイル header.php を編集し削除しました。

d-2.Amazonアソシエイト

Product Advertising API を使うと解決します。
コード直貼りから Product Advertising API を使うプラグイン AmazonJS を利用することで対応しました。

e.外部サイト登録情報更新

以下の設定を変更しました。

Facebook Apps Setting
Twitter Application Management Settings
ウェブマスターツール
Google アナリティクス

f.HTTPS へのリダイレクト

SSLのみアクセス許可の設定（SSLアクセス強制のため、http://～は https://～へリダイレクト）を .htaccess に記述します。

「さくらのレンタルサーバー対応」と同様に環境変数で「SSLでなければ」の判断ができないので、単純に設定すると「httpsで始まるURLにリダイレクト」したものがSSLでないと判断されてまたリダイレクトされ、ループになってしまいます。

${ENV:HTTPS} が 'on' でなく、かつ、%{HTTP:X-Sakura-Forwarded-For} が未設定の場合、https://%{SERVER_NAME}%{REQUEST_URI} へリダイレクトとすれば良いようです。

&lt;IfModule mod_rewrite.c&gt;
    RewriteEngine On
    RewriteCond %{ENV:HTTPS} !^on$
    RewriteCond %{HTTP:X-Sakura-Forwarded-For} ^$
    RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
&lt;/IfModule&gt;
   
# BEGIN WordPress
&lt;IfModule mod_rewrite.c&gt;
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
&lt;/IfModule&gt;
# END WordPress

RewriteEngine On

RewriteCond %{ENV:HTTPS} !^on$

RewriteCond %{HTTP:X-Sakura-Forwarded-For} ^$

RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R,L]

</IfModule>

# BEGIN WordPress

RewriteEngine On

RewriteBase /

RewriteRule ^index\.php$ - [L]

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule . /index.php [L]

</IfModule>

# END WordPress

5. HTTPS化したときの不具合

HTTPS化することにより、現時点2点の不具合が見つかり、それぞれ以下の対応を行いました。

a.予約投稿ができない

wp-config.php で代替 Cron を ON にする。

define('ALTERNATE_WP_CRON', true);

1	define('ALTERNATE_WP_CRON', true);

これで解決しました。

b.NextScripts: Social Networks Auto-Poster で Twitter の画像投稿に失敗する

Twitter と Facebook に WordPress の投稿に連動投稿するプラグイン NextScripts: Social Networks Auto-Poster ですが、Twitter の画像投稿に失敗するようになりました。

NextScripts: Social Networks Auto-Poster のログによると以下の通りです。

Could not get image (https://画像アドレス), will post without it - Error:WP_Error Object ( [errors] => Array ( [http_request_failed] => Array ( [0] => 転送が多すぎます。 ) ) [error_data] => Array ( ) ) | PostID: 3112

「転送が多すぎます」なので、「http://～から https://～へのリダイレクト」を止めたら Twitter の画像添付に失敗することはなくなりました。
他の対策が見つかるまでは「http://～から https://～へのリダイレクト」は無しで運用することにしました。