エックスサーバーなど、ワードプレス無料SSL（Let’s Encrypt）設定、正しい方法！

エックスサーバーが無料SSLの Let’s Encrypt に対応しました！ レンタル共有サーバーはルート権限が無いので出来なかったのですが、嬉しいサービスですね！

では、緑色の錠マークがついたブラウザURLを目指して、サクッと手順に行きましょう！

この記事内の　DATABASE SEARCH AND REPLACE SCRIPT IN PHP　の使い方は、データベースにMySQL（ Maria DB ）を使い、ワードプレスを運営しているレンタル共有サーバーやVPSやクラウド全てに当てはまると考えられます。

SQLサーバーやPostgreSQLなどに関して　DATABASE SEARCH AND REPLACE SCRIPT IN PHP　適用可否のテストは行っておりません。

※作業を間違って、真っ白画面になっても焦らない様に、必ずデータベースと各種ファイルのバックアップを取得してから行いましょう！

エックスサーバーそのものをSSL対応にする

エックスサーバーのインフォパネルではなく、サーバーパネルにログインしてＳＳＬ設定、そして独自ＳＳＬ設定の追加に進みます。

その画面で、ＳＳＬを適用するサイトを選び、『独自ＳＳＬ設定を追加する（確定）』のボタンを押します。

エックスサーバーのサーバーパネル内で行う作業はこれだけです。

Let’s Encrypt とエックスサーバーの間で証明証関連のやりとり（取得など）を自動で行ってくれるので、待ちましょう。

Xサーバーからのメッセージでは、SSL設定が反映するまで、最大1時間程度とのことです。

データベース内のドメインを書き換える

➀ブラウザで緑ではないグレー（もしくは赤だったかもしれません）のhttpsに変わった事を確認後（SSL化が完成していない作業途中という事になります）、ドメインの書き換えでは　DATABASE SEARCH AND REPLACE SCRIPT IN PHP　を使います。phpmyadminでSQL置換しないでください。phpmyadminやSQLコマンドによるドメイン書き換えは、ワードプレスのウィジェットや画像ファイルのエラーとなり、失敗するものが有ります。ワードプレス特有のデータベース格納のシリアライズを理解する必要が有り、wp-admin/options.php　にて、そのoption値がSERIALIZED DATAであるかどうか該当確認を出来ます。

➁ダウンロードしましょう。

➂『 Search-Replace-DB-master 』のフォルダを丸ごとワードプレスのwp-contentやwp-config.phpのある階層と同じフォルダにFTPやSSHでアップロードします。

➃ブラウザで　https://『ワードプレスのトップページのドメイン』/Search-Replace-DB-master/　に進むと以下のような画面が出たらドメイン書き換えの準備完了です。

画像➀に、SSL化する前のドメインを入れます。

画像➁に　https://469-24.com　の様にSSL化の後のドメインを入れます。

※ use regex は正規表現を使いたい方向けです。

画像➂には、wp-config.php に既に記載されているデータベースのアカウント各種が勝手に表示されます。

※基本的に何もいじる必要はありません。結構デリケートなアカウント達なので、外部に漏らさない様に気を付けてください。

画像➃の dry run をクリックすると、予行演習としてデータベースの中のどの部分を何箇所書き換え出来ます！という一覧表が表示されるので押してみましょう。dry runの後、viewをクリックすると、データベース内のフィールドで置換前と置換後の比較シュミレーションも出来るので安心便利です。Windowsであれば、Ctrl+Fで検索窓をクロームブラウザに表示させ、該当文字列を検索してハイライトさせると見やすいです。dry runは超便利です。

置換前後のシュミレーションに問題が無ければ、画像➄の live run をクリックで実行です。

live run終了後、『 Search-Replace-DB-master 』のフォルダを丸ごと消すために画像➅ delete me をクリックして作業完了です。残したままにしておくとセキュリティ的にマズイので使用するたびに削除してください。

90日のSSL証明証更新期限についても、エックスサーバー側で自動更新をしてくれます。素晴らしい。

また、Google Analytics についてSSL対応はログインして簡単に設定出来ますが、Search Console は登録やり直しで結構面倒です。

WP-CLIでも置き換え出来ます

WP-CLIでもコマンドでデータベース内でドメインなどのテキスト置換えが出来ます。Windowsの場合、TeraTermやCygwinでWP-CLIコマンドを使えます。WP-CLIがサーバーにインストールされていない場合、コマンド操作によるインストールが必要です。

WP-CLIのインストールはQiita WP-CLIの使い方 がわかりやすいです。

WP-CLIの置換コマンド詳細はこちらです。

//基本的なWP-CLIの置換コマンド
wp search-replace 'http://example.dev' 'http://example.com'

エックスドメインとウェブクロウでは使えなかった

初期ドメインのワードプレスを同無料レンタルサーバー内でお名前ドットコム独自ドメインに変更する場合です。

2016年12月10日の時点で、無料レンタルサーバーのエックスドメインとウェブクロウでは、DATABASE SEARCH AND REPLACE SCRIPT IN PHP は使えませんでした。

Linuxコマンドも使えないので、WP-CLIもエックスドメインとウェブクロウでは確実に使えません。

詳しく原因は調べていませんが、ナーバスなデータベース情報を扱うツールなのでサーバー運営会社側でXSSやCSRFなどのセキュリティ対策でしょうか。外部ドメイン会社の独自ドメイン+無料レンタルサーバーとして運用されてしまうと企業として収益が上がらない為、有料に仕向ける為に行っている、あたりかと思います

VCCWやVVVを使って仮想マシンを立ち上げて独自ドメインのSQLファイルを作る　or　素直に有料のXサーバー等を使って独自ドメインのSQLファイルを作ることになります。サーバー引越以上に手間でめんどくさい作業です。

エックスドメイン内で初期ドメインから独自ドメインへの移行を安請け合いして、痛い目を見ました。30分以内で終わる想定の作業が、DATABASE SEARCH AND REPLACE SCRIPT IN PHPを使えず、わざわざ仮想マシンまで立ち上げてSQLファイルを作りました・・・。行き場の無い怒りが生まれます。

SSHが使えない上に、DATABASE SEARCH AND REPLACE SCRIPT IN PHP　も使えない場合、究極の時間泥棒です。作業量も増えまくるので本来であれば全く金額上がります。

無料レンタル共有サーバーであれば、文句は言えませんが、色々な選択肢として今後、『無し』です。

プロキシサーバーのキャッシュが遅い

エックスドメインとウェブクロウの件は、お名前ドットコムで取得したドメインで実験していました。aguseとかお名前ドットコムのドメイン詳細⇒ネームサーバー情報で確認すると、比較的に速くホストIPの変更確認が出来ました。ICANNを筆頭にレジストリ、レジストラの反映はそれほど遅くない。DNSレコードについてであれば､TTL調整でコントロールしやすくなります。

が、pingコマンドで確認するとなかなかホストIPが変わらない。遅い原因はおそらくホップしているプロキシサーバーのキャッシュ。キャッシュを消しにいきたい、笑。

ダッシュボード内でURLを変える。

ワードプレスのダッシュボード内で「設定」⇒「一般」で URL を https://dev-labo.com という感じにSSL対応に変えましょう。

この作業の後、ブラウザをリロードして緑の錠マークが付いたhttps://dev-labo.comが見られれば完成です。

ページによっては、mixed content（非httpsのhttpから始まるソースコードやリンクなどが入っている事）が発生しているかもしれませんので、面倒ですがサイトのページ全部を見直してチェックされる事をお勧めします。

Let’s Encrypt には偉業をしてくれて感謝！ Let’s Encrypt は広告と上位SSLを収入とする業態でしょうか？

無料SSLを作り上げてもらった後に潰れてもらっても困るので・・・。

最後に、.htaccessをSSLのドメインへリダイレクトする様に書き換えましょう。セキュリティを学習したことが無い人の場合、わからない項目が多くお勧め出来ませんが、iThemesSecurityプラグインでSSLのリダイレクト設定が簡単に出来ます。iThemesSecurityプラグインは正しく設定しないとGoogleBotをしらっと普通に蹴ります！サーチコンソールでインデックスがいきなり激減してゼロになり、超焦ります。

緑色の鍵マークにならない場合

データベース内のドメイン書き換えにMySQLコマンド/ダンプしたSQLファイル/phpMyadminを使ってしまった

SQLコマンドによる書き換えやSQLファイルの書き換えでは、データベースに各種データを格納する際のphpシリアライズに対応する事は出来ません。
必ず、シリアライズに対応している『Search-Replace-DB-master』や『WP-CLI』などを使ってください。※シリアライズは、データをデータベースへ格納する時に、データに暗号化の様な処理を加えるphpです。

画像ファイル（URL）がhttpの非SSLになっている。ソースコード内に非SSLが混じっている

Windowsであれば、F12でクロームディベロッパーツールのjavascript consoleやsecurityを確認するとmixed contentとして警告を確認出来ます。mixed content が1つでも残っていると緑色にならないです。mixed contentの箇所をすべて直す必要があります。

ワードプレスのファイル内にドメインを直接書き込んでいる

テーマやプラグインやコアの中などにdefine系の関数などではなく、直書きでテーマやプラグインなどのファイルにドメインを書き込んでしまっている場合です。phpがわからない人などに多いと思われます。Linuxのgrepコマンドやfindコマンドを使ってファイル内の該当部分を全て探し出し、書き換える必要があります。SSH接続が使えないレンタル共有サーバーの場合、探三郎などのツールを使う事になりますが、非常にめんどくさくて不便です。

LINE友達追加/PPC広告/feedlyのSNSボタンなど、SSL対応していない各種のタグがソースコード内に紛れ込んでいる

twitterは既にサービスそのものがSSL対応している事も有り問題ありませんでした。後述しますが、FaceBookPagePluginが厄介です。

緑色の鍵マークにならない場合の例外

クロームブラウザに、はてなブックマークのアドオンを入れていると、mixed content になります。はてなに対応してもらえるように依頼しました。

セキュリティ、油断/過信は禁物

ドメイン認証SSLを入れたからセキュリティは大丈夫！ではないです。基準はPCI DSSです。個人情報や決済機能を取り扱わないWEBサイトであれば、XSS（クロスサイトスクリプティング）やCSRF（クロスサイトリフォージェリ）や踏み台などで、他人のWEBサイトに迷惑をかけてしまう可能性などはありますが、不特定多数の個人に対してお金に直接関係する様な被害をもたらす事はないので、自社へのダメージ以外はそれほど心配しなくてもいいと思います。情報発信が一方通行で会員データを集めていないメディアサイトやブログサイトなどが該当します。しかし、EC-CUBEやCS-CARTやMagentなどで個人情報や決済機能を取り扱うネットショップなどを作る、もしくはphpやRubyのフレームワークなどで数千万円をかけて完全オリジナルのネットショップを作る場合は、年間の取引件数に応じて、PCI DSSの基準が定められ、対応する事が求められます。イニシャルの1次開発費で最低でも200～300万円はザラです。イニシャルの一次開発費5万でCMSによるネットショップを作ってくれ！という何も知らない人も世の中には多いですが、あり得ません。楽天RMSやアマゾンやすとあｋなど

出来る限りのセキュリティ対策を、お金/時間/技術者を永続的に投下して行っているか？

訴訟を起こされた場合の内容に影響します。お金も人手も使ってしっかりセキュリティ対策を継続していたけれども突破された！個人情報漏洩などが起きた！という場合、裁判官から見て情状酌量の余地は出てくると考えられます。Bene〇seの様に500円の商品カード送付だけ、その程度のコストで無理やり済ませられるかもしれません。セキュリティ対策を放置したり、避けながら利益を出してきた無責任なネットショップオ―ナーほど、高額な賠償金額となります。

なんとなくSSLを導入しただけで、サーバー面の運営責任をシステム開発会社に丸投げ放置して情報漏えいが起きる場合、システム開発会社とショップオーナーとの間で責任のなすりつけ合いが120％起こると予測されます。VPSやクラウド以上のサーバーを使っている場合、最終的に毎月のサーバー費用を払っている不勉強なショップオーナーの過失割合が大きく目立つことになると予測されます。

リスクをよく知っているシステム開発会社であれば、少なくともショップオーナーより詳しいので、システム開発会社側に有利な契約内容を事前に結ぶはずです。『金額相応な実装内容以上のセキュリティ責任は負えない』というラインをはっきり示します。弊社でもそうします。当然、技術面がわからない発注者には不利な契約内容となります。

この様なリスクを知らず、自社土俵でネットショップを自社運営したい、イニシャルの一次開発コスト10万円以下程度、毎月の運営コストは数百円のレンタル共有サーバーのみというのは、ナンセンスにもほどがあります。勉強不足、ビジネスオーナー失格です。もっと勉強しましょう。成功するショップオーナーはめちゃくちゃ勉強しています。ビジネスオーナーがWEBについてしっかり勉強しない、動かないから上手くいかない。

SSLには階級がある

SSLには大きく別けて3種類（ドメイン認証、企業認証、EV SSL）の階級があります。ドメイン認証は最下級戦士です。

root権限が使えないXサーバーのX10プランでは、Let’s Encrupt 無料SSLの実装はドメイン認証までが限界です。潔く見てみぬふりをするしかありません。その為、ネットショップの場合、root権限の無いサーバーでは、本来、運営するべきではありません。そして、無料ではない企業認証以上が基本です。セキュリティ的には、無料SSLでは、ショップを企画制作する段階から購入客を裏切る事になります。今後、不勉強のまま無料SSLのネットショップというのが増えそうですが、いざセキュリティ問題が起こった後に、『知りませんでした』と謝るだけというのは、経営者として悪質な非常に重い、危機管理能力不足も含まれている罪ではないかと考えています。

また、おそらく Let’s Encrypt の無料SSLで、3ヶ月に一度必要な証明証の自動更新までしてくれるレンタル共有サーバーは、今は、エックスサーバーだけだと思います。

WEBCROWが Let’s Encrypt をエックスサーバーよりも早く導入していたのを覚えています。自動更新の可否については不明です。

シェルスクリプトあたりで対応してくれているのでしょうか。どうやって自動更新を行ってくれているのか、エックスサーバー流のやり方はよくわかっていません。

通常、root権限のあるサーバーでは Let’s Encrypt のcertbotクライアントにsshの黒い画面でコマンドを打って自動更新のお願いが出来ます。

SSL対応済WEBサービス

• グーグルアドセンス
• グーグルアナリティクス
• Twitter

SSL非対応WEBサービス

• FaceBookPagePlugin
• A8.net（アフィリエイト）

FacebookはSSL導入済みでいかにも対応してそうな顔していますが、PagePluginのパーツをサイトに載せるとタイムラインの画像がイレギュラーに非httpsでMixedContentになります。厄介です。

httpレスポンスヘッダーをapacheならhttpd.conf、nginxならnginx.confなどで書き変える方法もありますが、以下のタグをheadタグ内に入れる方法が簡単です。

//MixedContent対策。headタグ内に入れてください。
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

ワードプレスの場合以下のソースコードを子テーマfunctions.phpに張り付けてください

//子テーマのfunctions.phpに張り付ける　mixed content 対策
add_action('wp_head','adds_head_ssl_nissy',1);
function adds_head_ssl_nissy() {
  echo '<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">'."\n";
}

アフィリエイト広告、SSL対応しているかどうか？

確認する必要が有ります。Googleアドセンスについては、SSL対応しています。SSLに変更しても設定したアドセンスのタグを書き換えるなど、面倒な作業は、弊社の他サイトでは特に発生しませんでした。環境によって異なる場合も有るかもしれません、慎重にご確認ください。