SNIとSANs比較メモ

SNIとSANsがごっちゃになるので備忘録

名称

• SNI :Server Name Indication
• SANs: Subject Alternative Names

適用分野

• SNIはTLSに関するクライアント側の技術
  (とはいえ、サーバ側でもSNIを受け付け可にしておく必要はある）
• SANsは証明書に関するサーバ側の技術

で、結局何者なの？

SNI

• TLNネゴシエーションする際にClient Helloに含まれるextensionでドメイン名が含まれる
• TLS規格に追加された属性(extension)の仕様
• なんで必要なんだっけ？
  • 暗号化しないhttp通信では、どのドメイン宛ての通信か判断する手段としてhttpヘッダのHost属性で判断が可能だが、暗号化されるhttps通信の場合はhttpヘッダが暗号化されているためHost属性の内容をサーバで判断できない。
    　このため暗号化前のサーバとクライアントのやりとりであるTLSハンドシェイクのClient Helloパケットにドメイン名をextension属性としてつけることでサーバがドメイン名を判断できるようにした。
  • サーバにある証明書が一つだけなら、どのリクエストに対しても持っている一つの証明書で通信すれば良いが、サーバによっては1台のサーバで複数の証明書を保持している場合がある。
    この場合、サーバはClient Helloに含まれるドメイン名から適切な証明書を選択することが可能になる。

SANs

• 一つの証明書で複数のドメインをカバーする
• X509規格に追加された拡張フィールド
• なんで必要なんだっけ？
  • なくてもクライアントの人たちは何も困らない、これまで通りhttpsアクセスすれば良い。
  • でもサーバ管理者はサーバ証明書の数が増えると、管理がとっても大変になるので、管理の負担を減らす技術。
    仮に12個の証明書を保持していて、有効期限が1年で発行日が全部異なる場合、サーバ管理者は毎月証明書更新作業が必要になる。万が一更新を忘れて有効期限が過ぎるとそのサイトにはアクセス不可になる、というおまけつき。
    だったら複数の証明書をまとめて登録できるようにしよう、そうだワイルドカード付きの*.abc.comみたいなフォーマットも許可しちゃえ、的な感じで生まれた。（妄想も入ってます）
    ブラウザからGoogleの証明書見ても、CN(CommonName)は*.google.comとなっているが、証明書のサブジェクトの代替え名という名称でSANsフィールドがあるが、そこには数十個のドメイン名が定義されていて、有効期間が３ヶ月。こんな数のドメインを一つずつの証明書で管理できないな。
• Chromeではすでに証明書のドメインチェックにCN（CommonName）でなくSANsフィールドを見ているとのこと。なのでCNあってもSANsがないとエラーになる。

まとめると

複数のドメインを管理する場合、SANsを利用することでサーバ管理者は管理する証明書の数が減り管理の負担が減る。もし1台のサーバで複数のドメインを管理する場合になっても、SNIでClient Helloがドメイン名を付与してアクセスしてくるので、（SNI対応済みのサーバが）どのドメイン宛てのリクエストか判断できる、めでたしめでたし。