常時SSL化とは

「そもそも常時SSL化ってなに？」という方は当サイトのコラム常時SSL化（https化）のメリットと必要性とはをご覧ください。簡単に説明すると、SSLサーバー証明書（以下、SSL証明書）をサーバーにインストールしてウェブサイト全体をSSL化し、ブラウザとサーバー間の通信を常に暗号化することです。数年前までは、ID・パスワード入力が必要なログインページやクレジットカード情報を入力するページのみSSL化することが主流でした。しかし、現在では様々なセキュリティリスクに対抗する必要が出てきたため、一部のページだけでなくウェブサイト全体を暗号化することが推奨されています。本コラムでは、常時SSL化のための事前準備～リリース後の事後処理までの全行程を紹介しています。

常時SSL化のための準備

さくらのレンタルサーバでは無料SSL化機能が用意されているので、個人のブログ等を運営している方は、マウス操作のみでサイトをSSL化することもできますが、企業サイトやショッピングサイト、クライアントのサイトなどを運営している方はそうはいきません。まずはSSL化する前の準備作業について説明しましょう。

非SSLファイルの洗い出し

サイトのSSL化を検討する際に、どのページをSSL化するのか？SSL化するにあたって問題は無いのか？といったことを検討しておく必要があります。

特に重要なのは、CSSやJavaScriptなどの外部ファイルを絶対パス（httpで始まるURL）で指定しているかどうかです。例えば、 http://example.com/ というサイトで、cssファイルが「css」というフォルダに格納してあれば、ソースコードは以下のような書き方で指定されているのが一般的です。これを相対パスでの指定と言います。この場合、ページのURLがhttpsになれば、自動的にリンク先もhttpsとなります。

【相対パスの記載例】

<link rel="stylesheet" href="css/sytle.css">

ところが、以下のように絶対パスで書かれている場合、ページをhttpsにしてもstyle.cssはhttpで呼び出されることになるため、後述のMixed contentエラーの原因となります。つまり、常時SSL化の前に絶対パスで指定されている部分を相対パスへ修正する必要があります。

【絶対パスの記載例】

<link rel="stylesheet" href="http://example.com/css/sytle.css">

外部ファイルのSSL化

同様に外部のJavaScriptライブラリなどを読み出している場合は、必ず絶対パスで記述されています。この場合、リンク先をhttpsに対応したURLへ変更する必要があります。これが変更できなければ常時SSL化はできませんのでご注意ください。

例えばjQueryの場合、以下どちらのURLでも読み込むことができます。http://～で指定している場合は、サイトをSSL化した際にMixed contentエラーが出てしまいます。

<script src="http://code.jquery.com/jquery.js"></script>
<script src="https://code.jquery.com/jquery.js"></script>

どうしても外部のSSL化された（https://～で始まる）サーバーが見つからない場合、ライセンス上問題が無ければ、自分のサーバーへコピーして相対パスで記述することも可能です。

常時SSL化の予行演習

可能であれば常時SSL化の予行演習を行いましょう。特に関わっているメンバーが、誰も常時SSL化の作業を経験したことが無い場合は、強くおすすめします。

検証環境や開発環境がある場合、まずそれらの環境を常時SSL化してみる、というのも選択肢の一つです。現在はLet's Encryptという無料のSSL証明書が普及したことにより、SSL証明書のコストを気にすることなくSSL化が行えるようになりましたので、ぜひ予行演習をやってみてください。

SSL証明書の種類やブランドの選択

予行演習後は、本番/商用環境で利用するSSL証明書の種類（認証レベル）やブランドを決めましょう。現在ではLet's Encryptのような無料のSSL証明書もありますし、約1,000円/年～20万円/年といった有料のSSL証明書が数多くあります。さくらのSSLでは、目的から証明書を選ぶページも用意していますのでぜひ利用してみてください。

「無料か有料の証明書で迷う...」という方は、当サイトコラムの無料証明書と有料証明書の違いも併せてご覧ください。こちらのコラムでも説明していますが、「さくらのレンタルサーバ」のようなレンタルサーバーであれば、Let's Encryptの更新システムはサーバー会社側で用意されています。しかし、VPSやクラウドといった管理者（root）権限のあるサーバーの場合、更新システムは自分でセットアップする必要があるため、無料とは言えハードルが高くなります。

また、利用しているレンタルサーバーによって、サーバー会社から提供されているSSL証明書しか利用できない（他社で購入したSSL証明書の持ち込みが出来ない）場合が多くあります。当サイトではSSLを意識したレンタルサーバーの選び方のコラムもあるので、サーバーの引っ越しを考えている方はこちらもご覧ください。

さくらのレンタルサーバでは、マルチドメイン証明書やワイルドカード証明書は利用できませんが、それ以外のSSL証明書であれば他社で購入したSSL証明書でも利用する（持ち込む）ことができます。ただし、サーバー会社によってはSSL証明書の持ち出しを禁止している、もしくは仕様的に持ち出せない場合もありますので、サポートサイト等で事前に確認しておきましょう。

証明書の選択時に注意すべきこととして、SSL証明書のライセンス形態があります。現在、多くのSSL証明書は「クラウドライセンス」などと呼ばれるインストールサーバー数が無制限のライセンスが発行されていますが、一部のSSL証明書では「サーバー1台につき1ライセンス購入が必要」というものもあります。購入時にはライセンス違反にならないよう、しっかり確認しておきましょう。

SSL証明書の購入

有料のSSL証明書を選択した場合、SSL証明書の購入が必要になります。申し込み準備～インストールまでの流れを簡単に説明すると以下のようになります。さくらのSSLで購入する場合、SSL証明書の種類やブランドによって購入方法が異なりますので、各商品の詳細ページをご確認ください。

• 1CSRと
  秘密鍵の作成
• 2SSL証明書の
  申し込み
• 3支払い
• 4認証・審査
• 5発行
• 6インストール

さくらのSSLで最も人気のあるJPRS ドメイン認証型は最短当日発行可能なSSL証明書で、認証方式はドメイン認証です。アドレスバーに企業名を表示できるEV証明書は審査が厳格なため、発行までに1〜3週間程度掛かる場合がありますので、利用したい方は時間が掛かることを覚えておきましょう。さくらのSSLで販売しているEV証明書、SureServer EV for SAKURAは最短7営業日で発行可能となっています。

常時SSL化作業

さて、いよいよ常時SSL化の作業へ入っていきます。基本的にSSL化の作業にはPoint of No Return（リリースすると引き返せないポイント）はありませんが、コンテンツの編集とリダイレクト設定の投入時は注意が必要です。特にリダイレクト設定の投入時は、リダイレクト情報などがブラウザにキャッシュされてしまうので、意図しない挙動をする可能性があります。

確認作業時には、キャッシュを全消去しても構わないブラウザを用意しておくと便利です。普段はChromeを利用している、という方はFirefoxなどをインストールしておくとキャッシュ影響を排除して動作確認ができるのでおすすめです。

サーバー設定（証明書のインストール）

レンタルサーバーを利用している場合は、コントロールパネルへ秘密鍵を投入した後、中間CA証明書とSSL証明書を設定するだけでSSL通信が有効になる場合が多いです。さくらのレンタルサーバでも、同様のステップでSSL通信を有効化することができます。

最近は簡単インストール機能を提供しているレンタルサーバーも多く、コントロールパネルのボタンを押して支払いをするだけでSSL証明書がインストールされる場合もあります。さくらのレンタルサーバでもJPRS ドメイン認証型の簡単インストール機能を提供しています。詳しい手順はサポートサイトをご確認ください。

管理者（root）権限を有するサーバーへインストールを行う場合は手順がより複雑になります。Apacheやnginxなど、それぞれの設定手順（各認証局のサポートページ等）に従って設定してください。秘密鍵ファイルと中間CA証明書、SSL証明書の3つを結合した証明書ファイルのパスを設定ファイルへ記述し、ウェブサーバーをリロード（もしくはリスタート）することで反映されます。

こうしたミドルウェアでは、基本的にテストモードで設定ファイルの記述をチェックする機能があります。例えば、nginx では 「nginx -t」コマンドを実行することで構文をチェックできます。スペルミスやSSL証明書の記述ミスを防げますので、ぜひとも実行をおすすめします。

ミドルウェアの設定ファイルから記述する場合、脆弱な暗号スイートの使用と古い暗号化プロトコル（SSL1.0～3.0、TLS1.0～1.1）の使用に関しては、特に注意する必要があります。せっかくサイトを暗号化しても暗号スイートや暗号化プロトコルが古い場合、データの改ざんや中間者攻撃を受ける可能性が出てきてしまいます。

また、サーバーの形態を問わず、中間CA証明書のインストールを忘れることが非常に多いです。中間CA証明書は、サイト閲覧者のブラウザが自動的に補完してダウンロードしてくれる場合もあるため、発見が遅れる場合があります。次の動作確認のセクションで、詳しい確認方法をご紹介します。

サーバー管理者向けの詳しい設定方法の解説は省きますが、参考文献としてプロフェッショナルSSL/TLSという書籍がおすすめです。SSLのなりたちや過去の秘密鍵危殆化事例、各種ミドルウェア設定方法の注意点等が網羅されており、初級者からサーバー管理者まで広くおすすめできる内容になっています。

動作確認

SSL証明書のインストールが終わったら、次は動作確認です。インストールしたサイト（https://～）にブラウザからアクセスし、証明書情報を開いてみましょう。意図した証明書が表示されれば、最初のステップは成功と言えます。証明書情報の確認方法はサポートサイトにも記載されています。

さくらのレンタルサーバを利用している場合、ここで「COMMON NAME INVALID」などのエラーが出ることが多いのですが、これはコントロールパネルのドメイン設定で「SNI SSL」を有効にしていないことが主な原因です。まずはコントロールパネルなどの設定を確認し、問題が無ければ次にブラウザでドメインとコモンネームが合致したSSL証明書がインストールされていることを確認しましょう。

さて、ここで油断してはいけません。SSL通信の動作確認は、実はブラウザだけでは99％不十分です。認証局の提供しているSSLサイトチェッカーを利用してみましょう。

ここでは、暗号スイートや暗号化プロトコルが問題無いか？中間CA証明書がインストールされているか？など、様々な項目がチェックできます。何かしら設定が漏れていたり間違っていたりする場合、項目が赤字で表示される可能性があるので各項目をチェックしてみましょう。レンタルサーバーを利用している方は、暗号スイートや暗号化プロトコルを選ぶことができませんが、中間CA証明書のインストール有無は確認できるので、ぜひチェックしてみましょう。

コンテンツの編集

ひと通りSSL通信の疎通が確認できたら、次はコンテンツを編集していきます。準備段階で編集が必要な箇所はリストアップしていると思いますので、最初に説明したようにファイルパスはできるだけ相対パスへ、どうしても絶対パスが必要な箇所はhttps://のURLへ書き換えていきます。

前項の動作確認でSSL通信が正常に動作していれば、リストアップした箇所を単純に書き換えるだけでSSL通信を利用した呼び出し方に変更されます。ここでSSL関連のエラー等が発生する場合は、正しく設定が行われていない可能性がありますので、ウェブサーバーの設定などを見直してください。

Mixed contentの解消

常時SSL化と切っても切れないのがMixed contentエラーです。Mixed contentとは、httpsページの外部ファイル（CSSやJavaScript）をhttpで取得している場合に発生するエラーです。解消するためにはhttpで読み込んでいるファイルをhttpsに変更する必要があります。

Mixed contentを探すためにはChromeブラウザなどの開発者（デベロッパー）ツールを利用します。Chromeの場合、デベロッパーツール画面の「Network」タブを選択すると以下のような画面が表示されます。Schemeの部分を見ると、すべてhttpsとなっていることがわかります。Mixed content エラーが出ている場合は、この列のどこかにhttpのファイルがあるため、そのファイルの呼び出し方を修正する必要があります。

設定が複雑化したWordPressサイトなどにありがちですが、WordPressのようなCMSを利用している場合、テーマやプラグインなどの設定画面にヘッダ画像や広告タグ、カスタマイズしたスタイルシートなどのパスを入力する箇所があるため、「サイト上でどのファイルがhttpかわかっていても、どこで修正していいかわからない！」という事態に陥ることがよくあります。

MySQLもしくはphpMyAdminの利用に慣れている方はお気づきかもしれませんが、データベース内を自サイトのURL（http://example.jp）で検索して置換するのが一番早い、かつ確実に作業を行うことができます。WordPressの場合、投稿データもデータベースに保存されているため、サイトのURLを含めた全ての自サイトURLを書き換えることができます。

同様にSSH接続が可能な環境であればシェルでログインし、構成ファイル内の自サイトURLを一括で置換することでファイル内の絶対パスも修正することができます。一括置換はリスクの高い作業なので、必ずファイル、データベースともにバックアップを取ってから実行するようにしましょう。黒い画面（CUI）やデータベースの操作に不安がある方は、面倒かもしれませんが1つずつファイルパスを編集していく必要があります。コンテンツ編集が終わり、ページ内ファイルの呼び出し方がすべて「https」になれば、いよいよリダイレクト設定などの事後作業に移ります。

常時SSL化の事後作業

リダイレクト設定

さて、苦労してやっとここまで来た常時SSL化ですが、今のままでは「httpsでもサイトが見られるようになっただけ」です。Google検索などで自サイトへのリンクを表示するとわかりますが、検索エンジンからのリンクは実は「http」のままなのです。

これをhttpsへ強制的に遷移させるのがリダイレクト設定です。リダイレクトには301と302がありますが、今回は恒久的な対応という想定で301（Moved Permanently）を利用します。さくらのレンタルサーバでは「.htaccess」ファイルが利用可能なので、以下のような記述でリダイレクトを設定することができます。

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
</IfModule>

「.htaccess」ファイルは保存した時点で反映されるので注意しましょう。nginxも同様のリダイレクトを設定することができます。

さくらのレンタルサーバでWordPressを利用している方は、常時SSL化プラグインという便利なプラグインを弊社から公式にリリースしていますので、ぜひ利用を検討してみてください。プラグイン内の有効化ボタンを押すと、WordPress内のURL置換やリダイレクト設定などが実行され、簡単にサイトを常時SSL化することができます。なお、プラグインを利用する場合も事前の準備は必要です。必ずSSL通信でサイトに接続できるようになってからプラグインを有効化してください。

リダイレクト設定が完了すると、Googleなどの検索エンジンからのトラフィックが徐々にhttpsサイトへ直接向くようになります。もちろん、httpサイトへアクセスがあってもリダイレクトされているため、最終的なアクセスはすべてhttpsサイトとなります。

リダイレクトを設定した後の動作確認は、準備段階で用意しておいた”キャッシュをすべて削除した”ブラウザで行いましょう。特にChromeブラウザは、リダイレクト情報やSSL証明書情報をキャッシュするため、動作確認には不向きです。

WindowsのWSLや、Macのターミナルを使える方は「curl」コマンドを利用して確認するのもおすすめです。

$curl http://www.sakura.ad.jp -I
HTTP/1.1 301 Moved Permanently
（中略）
Location: https://www.sakura.ad.jp/

「-I」オプションを付けることでHTTPステータスコードが表示され、リダイレクト設定をしている場合はリダイレクト先が表示されます。「curl」コマンドは結果がキャッシュされることが無いため、確実にリダイレクト先を確認することができます。

HSTSの設定

サイト閲覧者のブラウザ側にSSLの利用を強制させる、HSTS（Hypertext Strict Transport Security）という設定項目があります。SSL証明書の設定状況を採点するサイト（Qualys SSL Labsなど）では、これを設定しないとA+にならないこともあります。

例えば、httpのURLをお気に入りに登録している（ブックマークしている）サイトにアクセスした場合、HSTSに「1年間キャッシュする」という設定がされていれば、次回以降のアクセスは（最後のアクセスから1年以内であれば）httpsで繋がります。お気に入りのURLが修正されていなくても、次回からhttpsで繋がります。

「リダイレクトの設定をすれば、HSTSの設定は不要じゃないのか？」と思うかもしれませんが、リダイレクトはhttpに来たリクエストをhttpsに変更する処理のため、アクセス元がhttpを指定している限り、httpへのアクセスは減りません。HSTSは1度アクセスされたブラウザに、「今後からはhttpsでアクセスしてください」とお知らせし、且つ強制させる機能であるため、ブラウザのキャッシュが削除されない限りhttpsでアクセスされるので、よりセキュリティが高まります。

HSTSの弱点は1回目のアクセスがhttpになってしまうことですが、予めブラウザに「このサイトはhttpsでアクセスしてください」と登録しておくことができます。これが「HSTS Preload」です。こちらのサイトにURLを登録しておくことで、初回のアクセスからhttpsで接続させることができます。

HSTSを利用する上で注意が必要なのは、何かしらの事情でサイトを「http」に戻した場合です。例えば、HSTSで1年間のキャッシュが指定されている場合、次回以降のアクセスが（1年以内であれば）httpでアクセスされることはありません。このため、サイトがhttpに戻ってしまうと、いつも訪れていた閲覧者がアクセスできない状況に陥ってしまう可能性があります。また、HSTSのキャッシュ時間設定値は最低1年（31536000秒）となるため、これも注意が必要です。

現在HSTSの設定は必須ではありません。設定する場合は上記の内容に注意して設定しましょう。

各種計測ツールなどの設定変更

リダイレクトやHSTSの設定が終わったら、Google AnalyticsやSearch Consoleなどのマーケティングツール、アクセス解析ツールの設定URLを変更していきましょう。特にSearch Consoleは、httpsサイトのインデックスの進捗を追うことが出来るので、登録することを強くおすすめします。

Search Consoleを見ていると、徐々にhttpサイトのクリック数が低下し、逆にhttpsサイトのクリック数が伸びていく様子が確認できます。そして最終的にはインデックスがhttpsサイトのみになります。

こういったツールの設定変更は忘れがちなので気をつけましょう。

印刷物やリンクなどの変更

最後に印刷物や自サイトからのリンクなどを変更していきます。基本的にリダイレクトは半永久的に行うものなので、リンクを貼り替える必要も無いと言えば無いのですが、貼り替えられる・書き換えられるものに関してはhttpsへ修正していくのがよいでしょう。

まとめ

長々と解説してきましたが、いかがだったでしょうか？文字量が多すぎるこのコラムを見て、常時SSL化へのやる気を喪失された方も多いかもしれません。しかし、サーバー1台でシンプルな構成のWordPressサイトを運用している場合などは、慣れれば20～30分で常時SSL化ができるようになります。

既に常時SSL化は必須の時代です。新しいサイトを構築する方は、最初からSSLに対応させて作っている方も多いと思いますが、既存のサイトはまだSSL化が進んでいないのが現状です。Chromeブラウザでは近い将来、今よりも非httpsサイトへの警告表示が強化されるという見通しもあります。常時SSL化は作業が広範に渡り、漏れやミスの出やすい作業でもあります。本記事を参考に、慎重に作業を進めてみてはいかがでしょうか。