Qiita初投稿がファーストサーバのAdventCalenderという、
itamitoです。
なにを書こうかと思いましたが、itamitoが最近一番悩まされた、SSLサーバー証明書に関しての重箱の隅を書きます。
##SSLサーバー証明書に関する選ぶときの細かなあれこれ
2日目の投稿常時SSL化（AOSSL）に向け、合わせて点検・対応すべきことでもありましたが、昨今、常時SSL化の波が押し寄せてきています。
「うちのもHTTPS化するか～」
となったときのSSLや証明書の選び方は各販売元に任せるとして、選ぶ際に意外と見逃しそうな点を、どこかにまとめておきたいなぁと思ったので、オレ得的に記載します。
証明書のラインナップを見てみても…普通に…
- サーバー証明書の種類がある
- サーバー証明書のベンダーがたくさんある
- サーバー証明書のベンダーごとに証明書の特徴がある
- サーバー証明書のベンダー内でも仕様違いがたくさんある
といった具合で…複雑怪奇。その仕様に関するところでは、多くの会社が説明していますが、
- 認証レベル
- 暗号強度
- クライアント対応率
- シールの有無
- 金額
- 発行までの所要期間
- etc
とこれもまたたくさんあり、検討要素満載です。。
証明書のモノとしては同じなのに、細かく違っている…これじゃ、利用者は何をみたらいいか、わかりづらいですよね。
（いや、売ってる側として、すんません…
##
仕様面で見逃しがちだけど気をつけるべきこと（私見）
証明書を選ぶとき、認証レベルを気にしましょうとか、シールの有無は？みたいなことはまだ分かりやすいですが、次のようなものはどうでしょうか？
| 気をつける項目 | 内容 |
|---|---|
| ライセンス | 購入すべき枚数。サーバー単位とかコモンネーム単位とか |
| SANs | example.comのコモンネームで取得したら、www.example.comでも使えるようになる とか |
| 保証・補償 | もし証明書のぜい弱性とかで、証明書の機能をなさなくなったときの補償 |
| 中間証明書 | 有・無/クロスルートか否か |
正直、なんのこと？とか、あまり気にしなくていいんじゃない？ってなるかもしれません。
いや、でも…ちょっと気にしてみてください。
##
ライセンス
証明書を使う上で、１サイトのみを１台のサーバーで運用する場合は、ライセンスとしてはあまり悩む必要はありません。
ライセンシーとして、WEBアクセスするURLに含まれるホスト名をコモンネームとして１枚取得して、WEBサーバーに設定すればそれでいいからです。
これが、「複数台のWEBサーバーを持つシステムに適用したい」だとか、「証明書を使っているサイトがアクセス集中で重くなったので、CDNを導入したい。」となったときには簡単でなかったりします。
前者の「複数台の…」では、その台数分のライセンスが必要となったり、
後者の「CDNを…」では、証明書をコピーして入れる必要が出てくる場合がありますが、ライセンスで許してない場合があります。
ベンダーや証明書によりまちまちなのがライセンスで、
コモンネームにつき１枚とっておけば、何か所でも同じ証明書を適用してもよい、
といったライセンスのものあれば、
1バーチャルドメイン設定1個所ごとに１枚必要、
証明書仕様でSANsに登録されているものについてはそれぞれに１個所は許可する
といった特殊なライセンス体系のモノもあります。
※ちなみに当社のZenlogicでは、ここらへんの制御を全て機能化しています。死ねましたよ。
##
SANs
ここでいうSANsは、ベンダーごとに呼び名が違いますが、「特定条件下で、コモンネームと、そのコモンネームにwww.がついたものをSANsに入れて提供されること」を指したいと思います。(自動設定SANsとか、wwwオプションとか、2WAY-SANsとかベンダーによりいろいろな呼び名があります。)
この、コモンネーム意外にwww.付きでも利用できるようにしたSANs、実はベンダーごとにばらばらの仕様で提供されています。
一方のベンダーでは、
- 第2レベルドメインまでのコモンネームであればwww.も適用されるが、第3レベルドメイン以上でのコモンネームであればwww.は適用されない
他方のベンダーでは、
- 申し込まれればwww.は適用される
というような仕様違いがままあります。
ただ、この各社提供仕様が異なる状況を鑑みてか、CA/Blowserフォーラムでは統一化を図っているようです。
近々、呼び名も含めて統一されるかもしれませんね。
##
保証・補償
サーバー証明書が売りだされたころからあったと思っているのですが、証明書自体の危殆化などによって何らかの被害を被ったときに、補償を受けられることを謳ったモノがあります。
ただ…会社の業務内で、いろんなベンダーの補償を調べたことがあるのですが、これが結構マチマチなんです。
古くからのベンダーや、大手であれば、ついているほうが多いですが、中には保証なんてないものもあります。
無償のものであれば、無くても仕方がないと思いますが、有償のモノでは、どうかと思います。
中には、CPS(Certification Practice Statement)をよく読むと、「保証しない」と書かれているところもあります。
もちろん、これまで証明書の危殆化による被害は聞いたことが無いですが、気にされる方は見ておいたほうがよいでしょうね。
##
中間証明書
証明書と聞くと、発行されたもののみ設定、で良いと思われがちですが、実はそれだけでは足りない場合があります。
証明書本体と併せて設定するものが、中間証明書です。
たぶん、いま発行されているほとんどの証明書で、中間証明書も必要となっていると思います。
中にはクロスルートと呼ばれる方法で設定する必要があるものもあります。
クロスルートは古い端末からのアクセスをカバーするために設定するものです。
（ベンダーによって、クロスルートとそうでないものを選択できる場合がアリ、クライアント対応率はクロスルートのほうで記載されているような場合もあります。）
※これが結構厄介で、正常に設定されていない場合でも、主要なブラウザではエラーが発生しないことがあります。
OSやブラウザ自身が中間証明書を持っている場合や、過去アクセスしたキャッシュが残っている場合にエラーが見えなくなります。
##
唐突ですが…最後に…
つたない文章ですが、読んでいただけた方の役に立てていれば幸いです。
(これ、投稿後にあとからEDITできるのかなぁ…)