goods and life +

Let’s Encrypt や、Let’s Encrypt 祭りや!(嘘)

嘘なんよ…(´・ω・`)

ところで、最近は SSL に対応していないサイトに対して、GoogleChromeFirefox などの最新のブラウザがそのことをあえて強調したような、けっこう目立つ感じでの警告表示なんかをするように変更されてきてますよね。

別にうちはパスワードやらクレカ番号なんかを入力させるようなサイトではないんですけど、よく事情がわかってない人がそういう警告みたいなのを見た時どう感じるか。
いらぬ誤解を受けて印象悪くなるっぽいのも嫌だな〜って気もしないでもない。

 

で、SSL証明書だとか特に必要でもないような構成のサイトであっても、WordPress のブログにはコメント欄やコンタクト用のメールフォームもあるので、その時の通信が安全であることに越したことはないし、ユーザーにしてもそのほうがより安心だろうし。

でも SSL化したら暗号化とかベリファイとかするわけなので、その分の通信が遅く重くなるだろうし、そもそも SSL証明書の取得だとか対応だとか手間もコストもかかるじゃないですか。
儲かってるどころかそれどころじゃないわけなのにそんなことを負担してまでやってる場合なのかな〜、とは思ったんですけど…。

 

結論:Xサーバーの利用をおすすめ!

 

icon-hdd-o 以前にもちらっと書いたんですけど、inali はこのブログにはネットオウルのサーバー「ファイアバード」に WordPress をインストールして、「スタードメイン」で取得しているドメインを利用しています。

ファイアバードは低価格サーバーの割には安定していて、写真など画像をたくさん使ってもそんなに遅くもない(だけど別に速いってわけでもない)。

でも、同時アクセスが爆発的に集まるだとか、ブログで儲かるべ!みたいなことはやっていないので、低価格でも割と安定して使えているのはぶっちゃけそれだけでありがたいことなんだとか思ってます。
だから何?、とかいうな…。(´・ω・`)

最近はスタードメインで取得したドメインを使った迷惑メールだとか、そういうのがもうかれこれ何年かぜんぜん来なくなってる。
そんなクソ迷惑なメールのジャンプ先にあったファイアバード鯖を使った詐欺なサイトも今はすでになくなっているのかもしれないけど、常識のないアグレッシブなバカほどウザいものはないっすよね。

前はけっこう頭にきてネットオウルに逐一通報してやったりもしてたんですけど、そういうのもほんとになくなって、いたって平和。

なんかもう宣伝みたいですけど、このバナーは本当に宣伝(笑)
ちょうど今ちょっとお得なキャンペーンをやってますし。
そろそろ新しい年度に向かって何か始めたいと思ってる頃じゃないかな、とかね…。

 

Let’s Encrypt の SSL証明書を新規取得してみた

で、これを見てまず勘違いしてですね…、

コモンネーム(ここの既存のドメイン、catchymood.com)で Let’s Encrypt の SSL証明書の新規取得申請をして、すんなりと CERT(SSL証明書)と中間証明書、そして秘密鍵の3つを取得してみたんですよ。
SSLボックスならコモンネームさえ間違えなければ(スラッシュだとかそこらへんの事なんだと思う)ほんとうに簡単。

Let’s Encrypt、日本語化してまとめてくれている Let’s Encrypt 総合ポータルを読んでみても、これちょっと詳しい人向けすぎて、何をいってるんだか意味すらわかんないやという人のほうが多い気がするんですけど。
それがすんなり取得できちゃう SSLボックスさんすげえ!って感じだったわけ。

 

で、“「Let’s Encrypt」は、ルート証明書「DST Root CA X3」対応の中間証明書をインストールする必要があります。” ってことなので、それらをどこにインストールすればいいかをちょい勘違いしたままに読み進めてみると、よく見るとこんなことが書いてあるわけ。

■ご注意
「Let’s Encrypt」「CoreSSLワイルドカード」「ラピッドSSLワイルドカード」においては、固定IPアドレスオプションがご利用いただけないために、ミニバード/ファイアバード/クローバーでのご利用が出来ませんので、予めご了承ください。

もしかして何もしなくてもそのまま使えるだとか、固定IPアドレスオプションを別途追加で購入したら使えるのかもとか思っちゃってた Let’s Encrypt の SSL証明書は、たとえ固定IPアドレスオプションを取得してもファイアバードでは使えないってことだった…。

ぶっちゃけ「ラピッドSSL」や「クイックSSLプレミアム」なら使えるってことなんだろうけど、ここらの情報はよく読まないとどうにもわかりにくい印象。
もうちょっと伝わりやすく書いてくれてたらいいのにな〜って感じで。

 

icon-hdd-o その点やっぱエックスサーバーがいい、オススメ。
エックスサーバーだと、新規加入すれば Let’s Encrypt とか無料で使えちゃうし、今から新しくブログなんかを作るんだったらすごくいい、性能もいいし速度も遅く感じないし、今ならドメインまでもらえる。

契約価格も以前よりも 100円安くなってるし、いまやお値段もサーバー容量も転送量制限もだいたいファイアバードの2倍ほどの存在だからといって単純に2倍のコストが必要なんだとも言えないんですよね。

そもそもサーバーの CPU のコア数やメモリの量も変わるので、その分スペックも違ってきてこれだし、転送量も違うし、悪くないどころか最初っから特に苦労せずにそこそこ満足できる環境を構築できるのはエックスサーバーかなあ…、って気がします。
だってエックスサーバーを使っている人のブログなどを開けてみて、実際にそんなに遅く感じることもあんまりないですしね。

WordPress専用のwpXレンタルサーバーはSSD多重高速化は魅力だとして、指定日のサーバーID下にある対象データ一式を提供するごとに5,400円(税込)の手数料が必要なあの自動バックアップは評判よろしくないというか。
リバースプロキシによるキャッシュ処理とか Cloudflare で無料でもできるし、mod_rewrite対応とか国外アクセス遮断機能とかFTP・FTPSでの接続対応やDNS設定機能は他所でも下位でも当たり前にあるものだし、ぶっちゃけほんとXサーバーで十分だと思いますわ。

 

じゃあもう Cloudflare を使えばいいんじゃね?

まあ Let’s Encrypt の証明書どうすんのよ?、って感じなんですけど。
でも、『金がないなら知恵を使え、知恵がないなら手を動かせ』、みたいなことを松下幸之助がギャーギャー言ってたじゃない?

てことで、ない知恵を絞ってみたところ、ピコーン!っていう感じで Cloudflare を使えばいいんじゃね?、て思いついたわけです。

 

結論:面倒臭いですよ!

 

といっても、Cloudflare も前からずっと使ってたりするわけですけど。
めっちゃ速くなる、そのかわり Jetpack プラグインのコメントとは相性が悪く、たまに動作も不安定になる Rocket Loader™β版を Auto で使うのはいまはもうやめていて、目玉機能の Rocket Loader はマニュアルモードでごく一部に地味に使い、Cloudflare では他の機能をメインに使わせてもらってます。

とはいえ、無料版を利用させてもらってるだけのことなんですけどね(笑)
毎月高い利用料を払ってより効果的な機能を使っているユーザーや篤志家がいるからこそ、そのおこぼれにあずかることができているわけだ…。
テーブルから落ちたパンを犬が喰ってもいいじゃない、ってイエスが言ってた。

で、巷でよくいわれていた CDN(Global CDN の Caching) のことだけではなくて、たとえ無料の部分であっても、実は IP Firewall による Access Rules での Block list や Trust list、TLS 1.3 protocol、Automatic HTTPS Rewrites、Opportunistic Encryption、HTTP/2 + SPDY、IPv6 Compatibility、WebSockets、Limited DDoS protection、I’m Under Attack™ mode、Page Rules、JavaScript や CSS、HTML の Auto Minify、Always Online™、Server-side Excludes や Email Address Obfuscation、Hotlink Protection などなど、有益な機能がてんこ盛りで使えるようになっているんです。

 

しかも自分が借りているファイアバードのサーバーの帯域幅を喰う部分や、あと主にウクライナが多いけど、わけのわからん外国からいわれのないアタックがされたりしてるところを Cloudflare に毎日かなり助けてもらえてるんですよね、こんな感じで。

最近はリルートなどのトラブルも少なくて、サイトにつながらないやんけ!なんてこともほぼなくなってるし、もしもそんな場合には Jetpack から落ちてるでってメールが来るし、そんなときには一時的にキャッシュをバイパスさせるのも簡単だからほんと助かる。

で、Cloudflare のそういうサービスの中に、さらに Shared SSL certificate があったことを思い出して、じゃあそれを使ってみようかな〜と。
仕組みはこんな感じだけど、変な共有ドメインにならないのもメリットです。

Let’s Encrypt の SSL証明書を取得したものの結局使えないわけだからして、inali の場合は Origin server が一番上の状態になるので、Flexible SSL を利用するってかたちです。
ほんとうは一番下の状態みたいになることを目論んでたわけですけど撃沈。

 

そもそもなんで HTTPS に?
まあ、このブログはもともとがキーワードでブログをガンガンヒットさせて、SEOで集客して儲けよう!だとかいうブログじゃないですし、そういうことはやってないんですけどね。

なので、Google が HTTPS をランキングの要因にしたことなんかが HTTPS にしてやろうという動機なわけではなくて、GoogleChrome の「このサイトへの接続は保護されていません」「このサイトでは機密情報(パスワード、クレジット カードなど)を入力しないでください。悪意のあるユーザーに情報が盗まれる恐れがあります。」の表示だとか、たとえば 9to5mac.com なんかをみてたら「安全でないスクリプトを読み込もうとして云々」(でんでんではない)という表示がされてしまうのがなんだか単純に鬱陶しかったからです。

あと、とあるページの写真が flickr にジャンプするべくリンクされているとこんな感じとか。

そういうアラートが出てる時に、「スクリプトを読み込む」や、詳細設定をクリックして「安全でないサイトを読み込む」を選べば、そのページは読めるわけだし、ジャンプもできるんですけど、アドレスバーにある URLの https っていう文字が「赤文字」に変わって、しかも「二重の斜線」が入るわけですよ、いかにも「これはアカンやつ」って雰囲気が満々。

上にも書いたけど、よく事情がわかってない人がそういう表示を見たときに、いらぬ誤解を与えてしまってすごく印象が悪くなるんじゃね?って感じで。

 

HTTP から HTTPS への移行プロセスはちょっとした手間
で、HTTP から HTTPS への移行プロセスってのもちょっとした手間が必要で、いろんなことを漏れなくやらないといけないわけです。

これらの記事が両方とも 2015年1月頃のもの。
もうすでに 2年も前から詳しく書かれているわけで、この件ってトピックとしてはわりともう周回遅れな話題なのかもね〜って気もしますど、まだ移行してない人だってたくさんいるだろうし、そこはまあ個人のブログだしキニシナイ。

 

てことで、できることは一応全部やってみました(つもり)
といっても WordPress は CMS なので、http で書かれた所を https に置き換えたりする箇所は数的にも少ないことだし、忘れてて漏れや抜けがないように注意することは必要だけど、既存のリンクなどはプラグインで置き換えれば楽に済ませられますしね。

で、Cloudflare の無料部分でのサービスの中には、上で書いたようなものに加えて、さらに HSTS(HTTP Strict Transport Security) ってのまでちゃんとある。

そこで HSTSヘッダーの推奨の Max-Age (Header set Strict-Transport-Security の max-age)、それに付ける includeSubdomains や preload のオプションの設定やら、さらには No-Sniffヘッダー(X-Content-Type-Options:nosniff ヘッダーを送信して Internet Explorer と Google Chrome が宣言された Content-Type から MIME を傍受しないようにする)まで設定できてしまうわけです。
(実際の設定はこの通りにはしていないですけど)

こんな感じで正直けっこういいサービスだと思います、安全なサイトをより簡単に作れるように、日本のサーバー屋さんにだって頑張って有用な付加価値を付けて欲しいところ。
…ていうか、この持て余した Let’s Encrypt どうするんや、3ヶ月で消滅?、て感じで。
サーセン。

 

ついでに後処理みたいなもの
最後に、自分の.htaccess にリダイレクトの設定をして終了。

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.catchymood\.com$
RewriteCond %{SERVER_PORT} !^443$ [OR]
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://catchymood.com$1 [R=301,L]

これで一応 www あり・なしの振り分けと、http://catchymood.com でアクセスされた時に https://catchymood.com にちゃんとリダイレクトできてる感じです。
もしかしたら3行目は必要がないのかもしれないですけど。

 

Safari でアドレスバーに出てくる鍵マークをクリックするとちゃんと証明書も出てるし、このブログはいまのところもうこれでしのげたらいいかのも。

こんなだからまあちょっとカッコ悪い。けど、個人のだし、まあいいかって感じで。

ん〜と、この中に怪しいヘンなサイトとか混じってなきゃいいんですけどね…。
見た目ダサいけど、だってお金とか持ってないんだもん、無料なんだから仕方ないわ。
…食べ物送ってくれよ、死ぬ、早く…。(´・ω・`)

 

デメリットはあるのか?
設定したことよりも、後の整理のほうがけっこう面倒なんですよね、HTTP から HTTPS への URLの変更=プロトコルの変更=URLの変更を伴うサイト移転ってことなんだし。

あえてデメリットといえば、www あり・なしの場合なんかと同じ理屈で、検索エンジン的には http と https ではプロトコルが、というか物理的にサイトが別物扱いに変わるという認識になるので、そこらは Search Console を使って新たなプロパティの追加やら、それぞれのプロパティを指定して管理する必要があったり、サイトマップの作り直しも必要。

ページのインデックスもこれまた再度クロールされてインデックスされなおさなきゃいけないことになるので、元のようにインデックスがされ終わるまでにはしばらくの時間というか期間が必要だろうな、ってとこらへんですよね。
ぶっちゃけ今インデックスが0だから、もし企業のサイトなら恐ろしい状態。

“HSTS がユーザーや検索エンジンに悪影響を与えない場合は、必要に応じて、Chrome HSTS プリロード リストにサイトの追加を依頼してかまいません。” ということらしい。
https://hstspreload.org/

で、HSTS は自動的に HTTPS ページをリクエストするようにブラウザに指示する仕組みなんですけど、正直 HSTS を使用するよりも前に、本当はじっくりと不具合の対処やいろんな様子の見極めなども含め max-age を徐々に増やしたほうが良いなど、ロールバックの手法も複雑化するし、これはほんとにもっと様子を見てだいたい安定してからの後回しにしておけばよかった、てことで今は max-age=0分とかにしておいたw

だってまだインデックスもされてないし、内部リンクもまだだし、検索アナリティクスのところでやっとクエリやクリック数が出始めた瞬間みたいなものだし、バカさゆえの過ちということか…。

max-age も5分から始めて、1週間、1ヶ月、って感じで出てくる問題をすべて修正しつつ、エージングを増やしてから、って感じがセオリーのようで、最大エージングは少なくとも18週間=10886400秒でないといけない、ぶっちゃけこれは厳しい道のり。

If your site is committed to HTTPS and you want to preload HSTS, we suggest the following steps:
Examine all subdomains (and nested subdomains) of your site and make sure that they work properly over HTTPS.
Add the Strict-Transport-Security header to all HTTPS responses and ramp up the max-age in stages, using the following header values:
5 minutes:
max-age=300; includeSubDomains
1 week:
max-age=604800; includeSubDomains
1 month:
max-age=2592000; includeSubDomains
During each stage, fix any problems that come up and then wait the full max-age of the stage before you move on (e.g. wait a month in the last stage).
Once you’re confident that there will be no more issues, increase the max-age to 2 years and submit your site to the preload list:
2 years, requesting to be preloaded:
max-age=63072000; includeSubDomains; preload

HTTPSサイトから追加のリダイレクトを配信する場合、そのリダイレクトにはリダイレクト先のページではなくて、HSTSヘッダーが必要、で一旦このプリロードリストに含めると、もう簡単に取り消すことができない仕組み。
これはちょっとマジでちゃんとしとかなきゃ敷居も高いですね。

こんなだから、まだやらないというか、たぶんこの状態じゃもうやらないだろうけど。
まあそれでもググるさんに怒られるような変なことさえやってなきゃ、以前のインデックスが検索結果から消えてしまっているわけでもないだろうし、そのリンクをたどっても https のほうにリダイレクトされるようにしておけばそんなに心配するようなことでもないかとは思います、知らんけど。

結論:新規で HTTPS のサイトを立ち上げた方がマシ!

ごにょごにょやってる間、サイトにちゃんとつながらなかったり、開けても触ってる最中で表示が無茶苦茶だったり、アクセスしていただいていた人にもなんだこれって感じだっただろうし、なんか Fetch as Google もうまくいかなかったりもしてるし…。
ちょっと萎えてる。
もしかしたらまだそういう状態が時々発生するような用事もあるかもしれないし…。
というか何時間経ってもトップから下の階層にあるディレクトリが500エラーを吐くから浸透すらしてないのかもしれない、確認しても htaccess の書き方のせいでもない、でも下手すると /以下の記事部分がインデックスされないかもしれない。
(まあ Cloudflare側のサーバーでなんで500エラーが出るのか理由を探して、結局直したんですけどね、そういうの面倒だし、わかんなかったら敷居高いかもしれないし、安易にはオススメできません。)

他にも Chrome の Developer Tools の anonymous さんの言うには Parser-blocking, cross-origin script, https://ajax.cloudflare.com/cdn-cgi/nexp/dok3v=hogehoge/cloudflare.min.js, is invoked via document.write. This may be blocked by the browser if the device has poor network connectivity.
See https://www.chromestatus.com/feature/5718547946799104 for more details.って感じで、いろいろとダメっぽい。

AUTHORITY SECTION はこれでいいとは思うけど、詳しくないのでもうよくわかんない。

Fetch as Google でインデックスさせてその表示を見て確認などなど。

結局は500エラーの原因はそこらではなくて、Autoptimize というレンダリングブロックを減らすために使っているプラグインで Js周辺を少しでも触ると出るということを突き止めた、疲れた。

 

それと、使われる jQuery のバージョン を IE のバージョンで切り分けしてみたったという記事で書いた、アクセスされるIE のバージョンによって wp_head(); で使われる jQuery のバージョンを振り分ける、みたいな技はもうやめたった。

何でかというと、GoogleChrome のコンソールをみてたらあまりにも jQuery is not defined とか Uncaught ReferenceError: j$ is not defined の警告がたくさん出てるのでなんか嫌になった。
古いIEを未だに使ってる人は、そろそろ新しい安全なブラウザ使ってください。

 

で、本題に戻ると、ネットオウルのファイアバードは、スペックがいい感じのエックスサーバーと比べるとやっぱり体感でもほんの少しだけサーバーの反応時間が遅めな感じ。
なので、自分の WordPress のテンプレートから SNSのカウント関連とかそこらの時間を喰いそうなやつを思い切ってガッツリ削ってみたところ少し軽くなったような気がする。
エックスサーバーと僅差かな〜ってところまではそれなりに行けてるんじゃないでしょうか?
といっても自分の環境以外からアクセスしたことがないし、知らんけど。

 

結論:だけど、Xサーバーがオススメです。

だってHTTPSの導入も超簡単だし、何もしなくてもサーバーはそれなりに速いし。
なんにせよ、余計な苦労知らずなのは Xサーバーだからです。

 

icon-hdd-o サーバー・ドメインの取得はキャンペーンをやってる時がお得!

今『ミニバード』と『ファイアバード』でキャンペーンをやっていて、この期間中の申し込み分はサーバー初期設定の費用が無料になっています。

ファイアバードは 100GB/月額500円、ミニバードは 50GB/月額250円(ともに税抜)。
キャンペーン期間はどちらも 2017年2月3日(金)12:00 から 2月28日(火)18:00 まで。

ドメイン取得サービス『スタードメイン』のドメイン割引キャンペーンもあって、期間は 3月31日(金)18:00まで。

人気の高いXserverでは 2月28日(火)18:00 までのサーバー本契約でドメイン1個プレゼントのキャンペーン中です。

ブログとかサイトとかつくろうかな、って思ってるひとはお早めにどうぞ。

おはやめにね…(´・ω・`)

この記事にコメントする

Return Top