GoogleがSEOのランキング要因としてhttpsを優遇すると発表してからSSL対応というものをどうしようか考えたことがありました。その時は、SSL対応した方が良いのだろうけど、実際にやるとなるとお金もかかるし、手間もかかるのでそのうちで良いだろうという結論に至りましたが、無料でSSLサーバ証明書が発行できるサービスがあるというニュースをネットで見て気になっていました。

最近正式版なって、誰でも無料で使えるようになってみたいなので、実際にこのサイトもSSL化してみました。なおサーバのOSはCentOS 7.2.1511で、WebサーバはApache/2.4.6という環境です。

Lets’ Encryptとは?

改めてLet’s Encryptとは何かという所から調べてみると、

「Let’s Encrypt」とは、SSL(TLS)に利用できるサーバ証明書を無償で発行している認証局またはサービスのこと。2016年4月から正式なサービスを開始した。MozillaやAkamai、Cisco Systemsなどが支援しているISRG(Internet Security Research Group)という団体が運営している。ソフトウェアツールによって証明書の更新などの作業を自動化できる点が特長として挙げられる。

との事で、無料でドメイン認証のSSLサーバ証明書が発行できるサービスです。今まではSSLサーバ証明書を発行する場合、数千円~数万円までかかっていたものが無料で出来るというのはかなり画期的です。

しかしあえてデメリットを言うなら、ドメイン認証というSSLサーバ証明書の中でも信頼性が低いものとなっています。まぁこれは企業でも無い限り信頼性の高い証明書を取る必要も無いかなと思います。

もう1点のデメリットとして、証明書の有効期限が90日と短いです。とは言えこれもコマンド一発で再発行することが出来ます。また、その更新作業もcronを使って自動化してしまえば何もせず常時SSL化が実現できます。

Lets’ Encryptの証明書取得方法

さて、それでは実際に証明書を取得する方法を見ていきます。まず、CertBotと呼ばれるクライアントをgitを使って落としてくる必要があります。

// git cloneで落としてくる
git clone https://github.com/certbot/certbot

そうすると、certbotというディレクトリができますので、その中に移動certbotクライアントを実行します。

cd certbot
./certbot-auto

certbotクライアントを実行すると、自動的に必要なパッケージをインストール(もしくはアップデート)してくれます。

証明書を取得するためのコマンドを実行

必要なパッケージがインストールされたら、実際に証明書を取得するためのコマンドを実行します。

./certbot-auto certonly --standalone -d www.hogehoge.com

-d の後には、実際に証明書を発行するサーバのドメインを指定します。

また、すでにwebサーバが立ち上がっている場合、

The program httpd (process ID 2091) is already listening on TCP port 80.
This will prevent us from binding to that port.
Please stop the httpd program temporarily and then try again.

という様なエラーが出るので、一時サーバを停止する必要があります。

systemctl stop httpd

Apacheの場合上記コマンドで停止します。

初めてコマンドを実行する場合、最初にメールアドレスを入力する画面が表れるので、任意のメールアドレスを入力します。
その後は、規約を読んだ上で同意するようにとの表示が表れるのでAgreeを選択して同意します。

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/[ドメイン]/fullchain.pem. Your cert will
   expire on 2016-10-22. To obtain a new or tweaked version of this
   certificate in the future, simply run certbot-auto again with the
   "certonly" option. To non-interactively renew *all* of your
   certificates, run "certbot-auto renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

正常に処理が完了すると、上記のようなメッセージが表示されます。
これで証明書類がサーバに保存されました。

証明書が保存される場所

取得した証明書の実体は、「/etc/letsencrypt/archive/」に保存されています。
ただ「/etc/letsencrypt/live/」からarchive内にある最新の証明書へシンボリックリンクが貼られているので、実際はliveの方を指定しておけば問題ありません。

Apache側の設定

/etc/httpd/conf.d/ssl.conf
に、証明書を指定してあげればOKです。

SSLCertificateFile /etc/letsencrypt/live/[ドメイン]/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/[ドメイン]/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/[ドメイン]/chain.pem

バーチャルホストの設定

自分の場合バーチャルホストを使っているので、更に設定が必要でした。
上記証明書の設定も、こちらの方に書きました。

NameVirtualHost *:443

<VirtualHost *:443>
    SSLEngine on

    SSLCertificateFile /etc/letsencrypt/live/monochrome-design.jp/cert.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/monochrome-design.jp/privkey.pem
    SSLCertificateChainFile /etc/letsencrypt/live/monochrome-design.jp/chain.pem

    ServerName monochrome-design.jp
    DocumentRoot /var/www/html/monochrome/
</VirtualHost>

Apacheの起動

Apacheを再起動して上記設定を反映させます。

systemctl restart httpd

httpsでアクセスしてみる

それではhttps付きでアクセスしてみます。問題が無ければアドレスバーの所に緑色の鍵マークが表示されるはずですが、どうも警告が出ている様子。

エラーが出ている様子

警告の原因は、内部的に読んでいる画像が、httpで始まるものを読んでいるため混在コンテンツとなっているみたいです。開発者ツールで見てみると、エラーの原因となる画像が表示されています。

内部リンクの修正

CSS内で指定している画像のURLや、記事の全てを見返して、httpから始まっているものを全てhttpsに変更しました
幸い(?)にも記事数があまり多くなかったので、全て手作業で地道に修正しましたが、記事が膨大にある場合ツールか何かで置換してやらないとつらいと思います。

WordPressの場合「Search Regix」というプラグインを使うことにより、全記事から検索して一括置換が出来るそうです。

内部リンクを全て修正すると、アドレスバーに無事緑色の鍵マークが表示されました。

認証済み

リダイレクト設定をする

httpsで無事表示確認が済んだら、http→httpsへのリダイレクト設定を行います。301リダイレクトにすれば、SEO的な評価も引き継いでくれます。

リダイレクト設定は、Apacheの設定、もしくは.htaccessで出来ます。
当初.htaccessでやるつもりだったのですが、どうも上手くいかなかったので、Apacheの設定でやりました。

<VirtualHost *:80>
    ServerName monochrome-design.jp

    RewriteEngine on
    RewriteCond %{HTTPS} off
    RewriteRule ^(.*)$ https://monochrome-design.jp/$1 [R=301,L]
</VirtualHost>

をバーチャルホストの設定confファイルに追記してリダイレクト対応完了です。

WordPressの設定を変える

WordPressの「設定」>「一般」より、WordPress アドレス (URL)とサイトアドレス (URL)をhttpsに変更します。

Wordpressの設定を変更

Google Search Consoleに登録する

http と https は別物として認識しているため、Search Consoleに登録する必要があります。
また、インデックスの移行状況を把握するために、今までのものはそのまま残しておくのが良いかもしれません。

それと忘れずにやっておきたいのが、サイトマップの登録です。こちらもURLが変わるので新たに登録する必要があります。

なお、Wordpressの場合、プラグインでsitemap.xmlを生成している人が多いと思います。
WordPressの設定を変更すれば、自動的にhttpsのものになるはずですが、念の為確認しておいた方が良いと思います。

sitemap.xmlの確認

なお自分は「XML Sitemap Generator」というプラグインでsitemap.xmlを作っています。

Feach as Googleをしておく

一通りSearch Consoleでの設定が終わったら、Fetch as Google をしておくと、より早くhttpsでインデックスされる、、、かもしれません。
気休めかもしれませんが、何もしないよりは良いと思うので、やっておくと良いでしょう。

Google Analyticsの設定を変更する

analyticsの設定変更

Google Analyticsの「プロパティ設定」と、「ビュー設定」内に、ウェブサイトのURLという項目があるので、こちらをhttpsに変更します。

SNSのシェア数なんかは引き継げる?

httpとhttpsで別URLなので、リセットされます
ただ、Wordpressを使っていて、「SNS Count Cache」というプラグインを使っている場合、内部でhttpとhttpsの数字を合算して擬似的に数字が引き継げます。

SNS Count Cache設定内の「シェア基本キャッシュ機能」>「HTTPからHTTPSへのスキーム移行モード」を有効にすれば合算して擬似的に引き継いでくれます。なんという神機能。

SSL化してどうなったか

Google Search Console上では、順調にインデックスされていっています。
アクセス数は一時的に落ち込むかと思ったんですが、それほど変化はありませんでした。

正直まだ大きな変化は無いみたいですが、googleがSEOの要因としてhttpsを評価すると言っている以上、なるべく早くSSL化はした方がいいんじゃないかと思います。特にブログの様なものの場合、記事が増えれば増えるほど内部リンクの修正など、移行するのがどんどん大変になるので、出来るときにやっておくのが良さそうです。