planet-green.com

[開発/備忘録] 個人でSSL証明書を取得してHTTPS化してみた話



個人でSSL証明書を取得して当サイトをHTTPS化してみました。
証明書はGeoTrust社のRapid SSLです。

実はその少し前に無料のLet’s Encryptを試しに入れていたのですが、次章で書く懸念事項があり、Rapid SSLが3年間3,200円(税別)と安かったので購入することにしました。ちなみにニジモさんで購入しました。

Let’s Encryptについて

無料なのは大変ありがたいです。理念も素晴らしいと思います。

証明書を取得・更新するためには、一時的にWEBサーバー(Apacheやnginxなど)を停止し、専用のスクリプトを走らせる必要があります。

このスクリプトはサーバーの80ポートまたは443(SSL)ポートを独占して認証サーバーのAPIにアクセスし証明書を取得するようです。
(おそらくサーバーの所有者であることを確認するためにそのようにしているのでは無いかと思います)

証明書は90日ごとに更新が必要なので、サーバー管理者が手動で行うか自動化スクリプトをcronで登録する必要があります。

怖いのは、いつか忘れた頃にLet’s Encrypt側のAPI仕様やURLが変更されて自動更新に失敗したり、無料サービスが打ち切られてしまうことですね。

最初は無料で始まったサービスがいつのまにか有料になったり、大手企業に買収されて理念が大きく変質してしまった例を何度か見てきていますので・・。
(前者ならDynDNS、後者ならMySQLなどですね)

また、サーバーを管理する者としては、自分が忘れている間にWebサーバーが一時停止された後、何らかのトラブルで再起動に失敗するのが一番怖いです。

・・・と、懸念事項を思いつくだけ書いてみましたが、個人が趣味で運営しているようなサイトなら大きな問題にはならないでしょう。

しかし、商用利用してるサーバーや業務で扱うサーバーではリスクが大きいかもしれません。

Rapid SSLとFUJI SSLの比較

ニジモさんではFUJI SSLという日本のセコム社が販売しているSSLも取り扱っていて、こちらの方が3年2,400円(税別)と安かったので、購入時の比較対象としました。

ちなみに両者の対応ブラウザは次のようになっています。

RapidSSL

  • Internet Explorer ver.6以降 ※1
  • Chrome 1.0以降
  • Opera 9.5以降
  • Firefox 1.0.0以降
  • Mac OS X Safari 2.0以降 ※1
  • Android Ver.1.5以降 ※2
  • iOS Safari iOS3.0以降
  • Windows Phone 7以降

https://www.geotrust.co.jp/products/resources/compatibility_listing/より抜粋

FUJI SSL

  • Internet Explorer 8以上
  • Chrome(IEと同様 Windows XP SP3以降)
  • Opera 9.5以上
  • Firefox 12.0以上
  • Mac OS X 10.6.7以上
  • Android ver1.5以上 ※2
  • iOS ver2.0以上 ※2
  • Windows phone ver7以上

https://www.fujissl.jp/certificate/cer-browser/より抜粋

※1 実際にはSHA-2(SHA-256)の制限があるので、IE7以降・Mac OS X 10.5以降になるはずです。
※2 中間CA証明書を追加する必要あり。
 
携帯電話、いわゆるガラケーに関してはFUJIの方が対応率が高いようですが、当サイトに携帯からのアクセスはほとんど無いので気にしないことにします。

IEに関してはVer.7を使っている人はもうほとんどいないので問題ないのですが、Mac OSに関しては、当サイトはMac関係の記事も書いているせいか、アクセスログを見ると10.4や10.5のユーザーが稀にいるのです。

これら古いMac OS Xのサポートはとっくに切れているので使い続けるとセキュリティ的に危険なのですが、現実としてまだ使い続けている人がいる以上、完全に切り捨てるわけにもいかないというところです。

(本当は切り捨てた方が、新しいOS・ブラウザへの移行を促すのでいいのかもしれないですけど)

というわけでRapid SSLを導入したのですが、個人的には、今回の有効期限が切れる3年後ならFUJI SSLにしてもいい時期かなと思います。両者とも最近のスマホには完全対応しているので、スマホ向けサイトなどであればFUJI SSLは魅力的な選択肢になるのではないでしょうか。

古いブラウザへの各社のSSL対応状況

ここでちょっと気になったので、大手サイト各社の古いIEへのSSL対応状況を調べてみました。(2017年4月現在)
以前、仕事で各ブラウザでの動作確認用にVMwereに入れたWindows XPを複数種類用意していたのを手元に残していたので、それを使いました。

Internet Explorer 8
IE8でyahoo IE8でtwitterIE8でyoutube

Yahoo、Google、facebook、Amazon は表示できました。
Twitterはモバイル用のページに飛ばされましたが表示は出来ました。
YouTubeはSSLは対応してますがサイト自体が対応してないようです。

Internet Explorer 7
IE7でYahooを表示IE7でGoogleを表示IE7でTwitterを表示
IE7でAmazonを表示

Yahoo、Google、facebook、Amazon は表示できました。
Twitterはテキストは表示されますが画像が表示されませんでした。

Internet Explorer 6
IE6でYahooを表示

さすがに全滅でした。これは対応ブラウザの問題というより、SHA-2移行のためだと思われます。

本当はMac OSでも検証したかったところですが、手持ちの仮想マシンがありませんでした。

 

個人でRapid SSLを取得する

さて、話は戻ります。

いざ個人で取得しようとした時にCSR(Certificate Signing Request/署名要求)をどのように入力すればいいのか、ネットで検索しても情報がなかなか見つかりませんでした。

Rapid SSLは企業の実在性調査が無いので組織名は何を入力しても大丈夫かと思い、Organization Nameにはサイト名を入れて下記のようにしました。

Country Name (2 letter code) [AU]:JP
State or Province Name (full name) [Some-State]:Hokkaido
Locality Name (eg, city) []:Sapporo
Organization Name (eg, company) [Internet Widgits Pty Ltd]:PLANET-GREEN
Organizational Unit Name (eg, section) []:web
Common Name (eg, YOUR name) []:www.planet-green.com

(もちろん、ここで登録した”PLANET-GREEN”は、ただのサイト名であって法人登記しているわけではありせん。)

尚、SSL販売サイトには次の注意書きがありました。

RapidSSL、PositiveSSLをお申込みの型へ ホームページが未完成、ホームページに運営者情報が掲載されていない場合、会員制など、ログインが必要なホームページの場合、審査を通過さないケースが増えております。

RapidSSL、PositiveSSLをお申込みの方へ

ホームページが未完成、ホームページに運営者情報が掲載されていない場合、会員制など、ログインが必要なホームページの場合、審査を通過さないケースが増えております。

つまり、Rapid SSLでも運営者情報ページが必要ということでしょうか?

そこで、一時的に下記の運営者情報ページをトップページから辿れるところに設置。

一時的なサイト情報
代表者・所在地は、実際に調査されるわけでは無いので何を書いてもいいかもしれません。私の場合は特に隠す理由も無かったので正直に記載。SSLの申請をしてから認証されるまでの30分ほどだけ表示させておきました。

後からアクセスログを確認したところ、このページへの外部からのアクセスはありませんでした。運営者情報ページは不要だったのかもしれませんが、申請直後に届いた案内メールには下記の記述がありましたので、万全を期すならあった方がいいのではないかと思います。

(前略)
ご提出頂いたCSR(証明書申請データ)より審査を行います。
審査は自動化されたシステムにて行われますが、稀に人的
審査が行なわれる場合があります。

 

サーバーに設置

さて、証明書が届いたのでサーバーに設置。設置方法は検索すればたくさん出てると思うので割愛します。

ちなみに当サイトの動作環境は PHP7(php-fpm) + MariaDB + nginx + WordPress です。(2017年4月現在)

古いURL(HTTP)にアクセスがあったらHTTPSに301リダイレクトするように設定。SEO的に301を指定するのが重要です。

server {
	listen 80;
	server_name planet-green.com;
	return 301 https://$host$request_uri;
}

WordPressの管理画面 →〔設定〕→〔一般〕でURLを変更。

そしてDBの値を下記SQLで変更。

UPDATE wp_options SET option_value = REPLACE(option_value,'http://planet-green.com','https://planet-green.com') WHERE option_value like '%http://planet-green.com%';
UPDATE wp_posts SET post_content = REPLACE(post_content,'http://planet-green.com','https://planet-green.com') WHERE post_content like '%http://planet-green.com%';
UPDATE wp_posts SET guid = REPLACE(guid,'http://planet-green.com','https://planet-green.com') WHERE guid like '%http://planet-green.com%';
UPDATE wp_postmeta SET meta_value = REPLACE(meta_value,'http://planet-green.com','https://planet-green.com') WHERE meta_value like '%http://planet-green.com%';
UPDATE wp_commentmeta SET meta_value = REPLACE(meta_value,'http://planet-green.com','https://planet-green.com') WHERE meta_value like '%http://planet-green.com%';
※URLは各自の環境に合わせて書き換えてください。

WordPressのプラグインで同じ機能のものがあるようですが、直接DBを操作できるならこの方が早いのではないでしょうか。(ただしご利用は自己責任で。事前バックアップは忘れずに!)

そしてブラウザで表示した時に鍵アイコンが緑になっていることを確認。

ブラウザの保護された通信の表示

ジオトラスト・インストールチェッカー でチェックして問題なければ完了。
(ジオトラスト以外も各社がSSLサーバー証明書インストールチェッカーを提供しています。)

WebサーバーのSSL設定をIE8など古いブラウザにも対応させようとするとインストールチェッカーで満点を得られないのがジレンマです。

そもそも、どうしてHTTPS化?

ただの個人サイトなのにどうしてHTTPS化したかと言いますと、やはりgoogleがHTTPS推奨を表明したのが大きいです。

Google ウェブマスター向け公式ブログ: HTTPS をランキング シグナルに使用します

良かれ悪かれ、WEBに携わる者がgoogleの掌の上で踊らされている状況はまだまだ続きそうです・・・。

他の理由としては、HTTP/2 を試してみたかったのと、WordPressの管理画面やphpMyAdminなどを操作する時にHTTPSだと安心できるという点でしょうか。
HTTP/2は、体感的はそれほど早くなったわけではないような・・・。PHP5.3から7.0に変えた時やキャッシュプラグインを導入した時の方が体感速度の向上は大きかったような気がします。

また、証明書はメールサーバーにも使えますので、SSL化すると安全性が高まります。
(特に、ホテルなど公共のLANに接続してメールの送受信をする時など)

コメント
planet-green.com

AWstatsのnginx環境へのインストール



AWstatsをnginxが稼働中のサーバーにインストールした時のメモです。

公式サイトよりダウンロードして /usr/share/awstats に展開。
http://awstats.sourceforge.net/#DOWNLOAD

# tar xzvf awstats-7.6.tar.gz 
# mv awstats-7.6 /usr/share/awstats

そして、〜/awstats/tools/nginx/awstats-nginx.conf に書かれている設定をnginxのサイト設定ファイルに追記すればいいのですが、私の環境では次のように書き直す必要がありました。

#
# AWstats
#
location ^~ /awstats/classes/ {
 alias /usr/share/awstats/wwwroot/classes/;
}

location ^~ /awstats/css/ {
 alias /usr/share/awstats/wwwroot/css/;
}

location ^~ /awstats/icon/ {
 alias /usr/share/awstats/wwwroot/icon/;
}

location ^~ /awstats-icon/ {
 alias /usr/share/awstats/wwwroot/icon/;
}

location ^~ /awstats/js/ {
 alias /usr/share/awstats/wwwroot/js/;
}

# Dynamic stats.
location ~ ^/cgi-bin/(awredir|awstats)\.pl {

 #↓必要に応じて追加
 #auth_basic "Secret Area";
 #auth_basic_user_file "/home/*****/.htpassword";

 #↓これを先に書かないと設定が上書きされてしまうのか正常に動作しない
 include fastcgi_params;
 #fastcgi_pass 127.0.0.1:9000;
 fastcgi_pass unix:/var/run/php5-fpm.sock;
 fastcgi_param SCRIPT_FILENAME /usr/share/awstats/wwwroot/cgi-bin/awstats-fcgi.php;
 fastcgi_param X_SCRIPT_FILENAME /usr/share/awstats/wwwroot$fastcgi_script_name;
 fastcgi_param X_SCRIPT_NAME $fastcgi_script_name;
}

あるいは、fcgiwrapを入れている環境では下記でも動きます。

fastcgi_pass unix:/var/run/fcgiwrap.socket;
fastcgi_index index.cgi;
fastcgi_param SCRIPT_FILENAME /usr/share/awstats/wwwroot$fastcgi_script_name;
include fastcgi_params;

この awstats-fcgi.php、コードを読むとperlスクリプトをシェルから実行して出力結果を返しているようで、なるほどと思いました。
nginxを導入してる環境でfcgiwrapをインストールしてるところは少ないと思うので、これはありかも。)

cp /usr/share/awstats/tools/nginx/awstats-fcgi.php /usr/share/awstats/wwwroot/cgi-bin/
mkdir /var/lib/awstats
chmod -R 755 /usr/share/awstats/

 

perl /usr/share/awstats/tools/awstats_configure.pl

上記perlスクリプトを実行し、設問に適切に答えてプロファイル名も登録すると、
サイト設定ファイルが /etc/awstats/以下に作成されるので下記項目を修正

LogFile="/usr/share/awstats/tools/logresolvemerge.pl /var/log/nginx/access.log /var/log/nginx/access.log.*.gz |"
# ↑実際のログファイル名に合わせて修正してください。

DirData="/var/lib/awstats"

DirIcons="/awstats/icon"

# SiteDomain,HostAliasesはサイトに応じて修正。

そして集計実行。

perl awstats.pl -output=pagetype -config=登録したプロファイル名)

するとブラウザで集計結果を表示できるようになります。

http://(サイトのホスト)/cgi-bin/awstats.pl?config=(登録したプロファイル名)

集計をcronで1日1回実行したい場合は、/etc/crontabに下記追加

05 15 * * * root /usr/bin/perl /usr/share/awstats/wwwroot/cgi-bin/awstats.pl -config=(登録したプロファイル名) -update 1>/dev/null 2>&1

CRONデーモン再起動

/etc/init.d/cron reload

・思い出しながら書いているので、間違ったり抜けたりしてる箇所があるかもしれません。

 


#追記 2017/03/11
2016年以降、Googleの全面HTTPS化に伴う仕様変更により、referrerから検索キーワードを取得できなくなりました。
今後、他社の検索エンジンも追随していくと思われます。
そうなると、残念ながらAWStats等のアクセス解析ソフトを導入する意義が半減してしまいます。

GoogleウェブマスターツールやGoogleアナリティクスを利用すればGoogleで検索された時の検索キーワードは取得できますが、他社の検索エンジンで検索された時の検索キーワードを取得するためには、それぞれの会社別の同様のツールを利用しなければならず、かなり不便になりそうです。

また、そうなった時にAWstatsのようなサーバーサイドのアクセス解析は完全に不要になるかというと、そういうわけではなく、例えば画像や動画などのメディアファイルに直リンクされた場合、GoogleアナリティクスのようなJavaScriptのタグをHTMLに貼り付けるタイプのツールではアクセス情報が取得できません。

ですので、AWStatsの存在意義が無くなることは無いのですが・・・・うーん。

 

コメント