StartComの無料SSL証明書が意外と良い件

2016年11月5日追記:
ただの失態だけなら良かったんだけど、Mozillaさんあたりがえらくお怒りのようで対抗手段を取られるようなので「がとらぼ」でも「ここの証明書はオススメしない」に変えておく。いつの間にか支那が絡んでて良いものも糞になる一例ってことかな。
Googleさんもアクション済みで、Chromeブラウザでは2016年10月21日以降に発行された証明書を信頼されなくなっている(それまでに発行された証明書は有効期限が来るまでは大丈夫)。
つまり、2016年10月21日以降にWoSignとStartComで発行された証明書はオレオレ証明書と同じなので一般に公開するサイトでは使用するのが不適切。

ドメイン用のSSL証明書が昔と違ってずいぶん安くなって年500円程度で購入できるけど、ここ数年は無料のもある。
時期的にはLet's Encryptあたりの話題の筈なんだけど捻くれてるので今頃StartSSLについて。
正直なところ、年500円程度なら痛くないということで無料のSSL証明書には手を出してなかったんだけど個人的に使う用のサーバまで有料のSSL証明書を使うのはもったいないし、かといってオレオレ証明書を使うのもイヤ。そこで今回使ってみたのがStartSSL(StartCom)の無料SSL証明書。有効期限は1年。

StartSSL1
StartSSLにアクセスして「StartSSL Free(Class1)」をクリック。この画面はまだわかりやすい。

StartSSL2
この画面はメッセージを読まないとわかりにくい。白枠最後の「Certificate Control Panel」というリンクをクリック。

サインアップを選択して入力。このあとメール確認が数カ所入るのでメールアドレスは嘘入力不可。CSRは自分で作ったものを登録することもできるしオンラインでも作れるみたい(自作CSRを登録したので未確認)。
サイトの画面遷移で待たされるのが嫌なら混まない時間にやった方が良さ気。
発行されるSSL証明書はドメイン名とサブドメイン名付き1つ。要するにexample.comとone.example.comの2つが有効。サブドメインはone.example.comで取ったら当然two.example.comは使えない。このあたりは極めて普通。サブドメイン名を任意で指定できるので有料の下手なところより優しいくらい。

サーバ証明書が表示される画面にIntermediate Certificate(中間CA証明書)のリンクも表示されるので別途取得する。
サーバ証明書とIntermediate Certificateをサーバに置いてゴニョゴニョする。

StartSSL3
こちらはブラウザ(Firefox)の設定画面で「認証局証明書」の証明書リストを表示したもの。StartComは最初から登録されている。(これ超大事)
無料SSL証明書の中には閲覧者側でそのルート証明書を入れなきゃならないのがあるけど、それだと規模が大きい「オレオレ証明書」というか「オレ達の証明書」なだけ。StartComは一般的なブラウザに標準登録されているようなまともな認証局で、そこが発行するStartSSLの証明書は閲覧者側からすると怪しげなところが無いということになる。

StartSSL4
SSL化したサイトを表示してブラウザのURL入力欄左横の鍵マークをクリックしたところ。
運営者の欄は「検証され信頼できる運営者情報はありません」で正常。
認証局の欄はStartCom Ltd.で正常。
下の方の「詳技術情報」の欄に「接続が暗号化されています(・・・・)」が表示されていれば正常。
[証明書を表示]を押す。

StartSSL5
表示された証明書の「詳細」タブを押す。「証明書の階層」の一番上がStartCom Certification Authority、次がStartCom Class 1 Primary Intermediate Server CA、その下がサイトのドメイン名になっていれば良い。

下手なところでSSL証明書を買うと中間CA証明書が複数必要だったりしたけどStartSSL(StartCom)のは1つで済むので寧ろこっちの方が良い感じ。
有効期限が1年なので更新の手間がかかるのだけが難点かな。(1年はあっという間に過ぎる)

StartComのログインにはStartComが発行する個人証明書がブラウザにインストールされていなければならないので個人証明書のインストールを拒まないこと。

サーバ証明書の発行を行う前に必ずドメインの所有確認(Domain Validation)を行わなければならないのでお忘れなく。postmaster@ドメインなどにメールを送ってくるのでそれを受信できないといけない。一度Domain Validationを実施すれば、そのドメインのサブドメインの証明書は複数発行可能。 (example.comのDomain Validationを実施すればhost1.example.com, host2.example.com, host3.example.comの証明書をそれぞれ取得できる。)

がとらぼのHTTP/2化

Nginx

昨日、「がとらぼ」をHTTP/2化しました。
直前にはINTAA.NETの公式サイトもHTTP/2化を済ませており、こちらではウェブサーバをApacheからNginxに切り替えるのに手間取りましたが、もともとSSL対応のサイトだったため、暗号化方式の変更以外には大きな問題もなく、比較的スムーズに移行できました。(ちなみに、今回の目的はHTTP/2化ではなく、元々予定していたApacheからNginxへの移行が主な理由でした)

一方、「がとらぼ」は、もともとNginxで運用していたため、簡単にHTTP/2化できると思っていました。しかし、元がSSL非対応のサイトだったため、実際にはHTTP/2化よりもSSL化に関する問題が多く、様々な不具合が発生しました。
サーバーの設定やSSL証明書の導入だけでなく、いくつかの技術的な調整が必要となり、思った以上に手間がかかりました。

たとえば、画像のURLを何も考えずに「http://」で指定していたことが問題になりました。Amazonの画像リンクも同様で、日本のアフィリエイトリンクは未だにSSL非対応が多く、結果としてリンクの修正作業が必要でした。
幸い、WordPressには「Search Regex」という便利なプラグインがあり、一括でリンクの置換ができたので、ほとんどの問題を迅速に解決できました。このプラグインがなかったら、相当手間がかかったと思います。
ちなみに、WordPress自体はHTTP/2対応において何の不具合もなく、心配していたトラブルは杞憂に終わりました。

NginxのHTTP/2に関連するディレクティブは、現時点ではすべてデフォルト設定のまま使用しています。特に調整を必要とせず、デフォルトの設定で十分なパフォーマンスを発揮しています。
年末ぎりぎりのタイミングでしたが、なんとか2015年中にこの作業を完了できたことは安心しました。

2015年12月17日追記:
AdSenseについては、SSL対応のサイトでも広告を表示できるのですが、SSL化されていない広告は表示されないという制約があります。つまり、SSL化することで表示できる広告の種類が減る可能性があるため、収益に影響が出るかもしれません。
「がとらぼ」のような趣味のサイトであれば問題ないですが、広告収入を重視するサイトの場合、現段階でのSSL化は慎重に検討する必要があると言えるでしょう。

Inside AdSenseからの引用
HTTPS 対応サイトでは、広告を含むページ上のすべてのコンテンツが SSL に準拠している必要があります。SSL 非準拠の広告は、HTTPS 対応ページに掲載する広告を決めるオークションから除外されるため、SSL 非準拠の広告は表示されません。
そのため、HTTP サイトを HTTPS サイトにした場合、HTTP ページに広告を掲載する場合よりも収益が低くなる可能性がございます。
関連記事:
Up