[常時SSL化(1)]Webサイトの常時SSL化

既存サイトの「作り」によって常時SSL化の難易度が異なる

ついに「Chrome68」がリリースされ、非SSL化サイトは「保護されていません」の警告表示されるようになった。（詳細は「ついにGoogle「Chrome68」がリリースされた！」参照）

そのため、自社サイトを始め、弊社クライアントのサイトも 続々と常時SSL化対応を行っている。

実は、常時SSL化は、既存サイトの「作り」や サーバー環境やによって、難易度が大きくことなる。

既存サイトの「作り」による難易度の差

サイト内のリンクパスを全て相対パスで記述してあれば、単純にSSL化するだけで ファイル等の修正は必要なく 常時SSL化できる場合もある。
が、絶対パス（http://から記述）してあるのであれば、それらを全て「https://」に書き換えてやらねばならない。

また、WordPress等データベース（DB）にコンテンツが記録されている場合は、DB内のデータも検索し、必要に応じ都度書き換え（変換）してやる必要がある。

サーバー環境による難易度の差

レンタルサーバーを使っていることが多いと思うが、まずは そのレンタルサーバーのプランが、「独自SSL」に対応しているかどうか、を確認してほしい。
安価なレンタルサーバーでは、独自SSL証明書を設定できないケースも少なくない。

そんな時は、独自SSL化できる環境（サーバープラン）へ「移転」する必要がある。

また、サーバーによってはコントロールパネル上から 簡単にSSL証明書の設定ができる場合もあるし、逆に証明書の発行、設定にとても面倒な作業が必要になるケースがある。

弊社では、VPSを契約し、そこで環境構築しているが、ドメイン毎の独自SSL証明書を設定しようとすると、IPアドレスを追加し、既存サイトをそのIPアドレスで動く様に設定変更した後、証明書を発行＆設定する、、などというかなり難易度の高い作業が要求される。
しかも、この間の作業は 全てコマンドラインからシェルコマンド等によって操作する必要があり、1つ間違えると、サーバー上の全てのサイトが閲覧できない、、なんて状態にもなってしまうことがある。。
まぁ、ここまで難易度の高い作業は、サーバー管理会社の方でやってくれるとは思うが。。

ということで、一口に「常時SSLする」と言っても、簡単にはいかず、数日間も苦労した挙げ句やっと出来る、といったケースもある。

なので弊社では、常時SSL化の要望があった際は、別に保持しているテストサーバーにて当該サイトの常時SSL化を実際に行って、手順を確立した上で 見積りを提示するようにしている。
簡単に構築できれば安価な見積りになるし、なかなか簡単にはいかず試行錯誤したり、技術的な変更・調整ヶ所が増えれば それ相応の見積りもなる。
簡単に安請け合いして、、後で実際に実施してみたらエラい大変だったことがあり、、慎重には慎重を重ねてスムーズな常時SSL化への移行ができるように努めている。
　
　
※データベースの対応については続編「[常時SSL化(2)]WordPressサイトの常時SSL化」をご覧ください。