【Web】SANsとSNIの違い
SANsとSNIがよくごちゃつくので完全に備忘録としてメモっときます。
そもそもサーバー証明書（SSL証明書)には通信の暗号化だけでなく認証の役割もあります。 接続先のWebサーバーの正当性を証明するためにはいくつかの観点がありますが、そのうちの一つに「証明証が示すホスト名（FQDN）」と 「ユーザーがブラウザに入力したホスト名(FQDN)」が一致するかどうか？というものがあります。
サーバー証明書が示すホスト名は、証明書のサブジェクト属性の中にある「コモンネーム」が知られていますが、最近は「SANs(サブジェクト代替名)(マルチドメイン名)」を使用するのが一般的になっているようです。
SANsを実際に確認してみましょう。
▶︎アドレス入力欄の左の鍵マークを右クリック→証明書をクリック
▶︎詳細な情報をクリック
証明書に関する情報を確認することができます。（発行元や証明書の有効期限、暗号化アルゴリズム...etc） SANsは以下の部分で確認できます。
ここに記されているホスト名と実際のサーバーのホスト名が一致していることを検証することでクライアントは目的のサーバーの正当性を確認するというわけです。
噂ですが、IEでは検証の際にコモンネーム(CN)とSANsの両方を見ているそうなのですが、Chromeなんかはコモンネームを見ずにSANsのみで確認しているのだとか。
では、このSANsって一体何？という話になってくるので、SANsについてまとめてみようと思います。
◆SANs証明書（Subject Alternative Names）とは
SANs（マルチドメイン証明書）とは、コモンネームに指定したドメインとは別のドメインをSANsと呼ばれる証明書の拡張領域に追加することで、一枚の証明書で複数のドメインを管理することができるというものです。 後述するワイルドカード証明書とは異なり階層に制限がなく、自由にドメインを設定可能なのが特徴となります。 ちなみに設定可能なドメインの数は認証局によって異なるのだとか。
また、正規表現(*)を使用することで、マルチドメインかつワイルドカードという証明書を作成することも可能です。（前述したYahoo!JAPANの証明書はまさにこのようなタイプです）
◆ワイルドカード証明書とは
ワイルドカード証明書とは、コモンネームのドメイン名に「」を使用することで、一枚の証明書で複数のサブドメインを管理できるようにするというものです。 例えば、「.example.co.jp」と指定することで、「www.example.co.jp」や「aaa.example.co.jp」をカバーできることになる。 ただし、コモンネームと異なる階層のドメインには使用できません。なので、「aaa.bbb.example.co.jp」というドメインはカバーできないというわけです。
SANs証明書もワイルドカード証明書も、一枚の証明書で複数のドメインをカバーできるという意味では同じですが、SANs証明書の方が自由度が高いといった感じですね。
◆では、SANs証明書やワイルドカード証明書だと何が嬉しいのか
一般に証明書の管理はサイトの数が多くなればなるほど面倒です。サイトが増える（証明書が増える）たびにCSRなどを準備する手間や購入する手間、有効期限の把握・更新の手間が増え運用負荷がなかなか堪らないものになります。 SANs証明書やワイルドカード証明書は単価が高いですが運用負荷を鑑みると導入メリットの方が大きくなるという考え方ができるわけです。
一方、デメリットもあります。 まず、ワイルドカード証明書はEV認証（最高認証）に対応していないという点です。 金融機関なんかのサイトではEV認証の証明書がよく使用されます。（日本の3メガバンクの証明書はすべてEVでした） 認証方式は他にもドメイン認証（DV）や企業認証（OV）があり、 EV > DV > OV の順に証明書の信頼性が低くなるわけです。 また、セキュリティの面でのデメリットをあげると、ワイルドカード証明書の秘密鍵が流出した場合、ワイルドカードでカバー可能な全てのドメインの証明書が危殆化してしまいます。SANsの場合も同様です。
◆SNIとは
今回の記事のタイトルは「SANsとSNIの違い」なので、次はSNI（Sever Name Indication）について整理してみようと思います。 SNIはSSL/TLSの拡張機能の一つです。 その特徴を一言で表すと、「1台のサーバー（一つのIPアドレス）で複数ドメインのSSL証明書を利用できる」ということになります。 SNI非対応の場合は「1つのサーバー = 1つのSSL証明書」ということになります。
例えばどこぞのホスティングサービスを利用してサーバーを借りる場合をイメージしてみましょう。レンタルサーバーでは1台のサーバーを複数のユーザーでシェアする形になるので、1つのグローバルIPをシェアしている全ユーザーで共有することになります。 そのサーバーでHTTPを使用するサイトを運営しているのであれば何の問題もないのですが、HTTPSを使用するサイトを運営したい場合、レンタルサーバーでは実現が難しいことになります。 クライアントからリクエストのパケットを送信する際の宛先IPは同一になるのですが、SSLハンドシェイク時には接続先のホスト名の情報をやり取りしないので、シェアしているどのバーチャルホストに対して接続したいのかが識別できないからです。
最近はフルHTTPS化が世界的に進んでいたり、独自SSLに対応したCDNやPaaS（AWS等）が増えてきたという背景もあり、従来の仕様だと不便になってきました。
そこで登場したのがSNIということになります。 クライアントがSSLハンドシェイクを開始する際に、「Client Hello」メッセージに目的のサーバー名を平文で含めるという動作になります。 そうすることで、サーバー側は自分宛のパケットのIPヘッダーを非カプセル化したあと、TLSのメッセージに含まれる目的のホスト名を確認することでどのバーチャルホスト宛のリクエストかを識別することができるようになるというわけです。
昨今の潮流からするに、SNIの需要も拡大していきそうではありますが、現状だとSNIに対応していないブラウザも存在するというデメリットもあります。
※画像引用元
【図解】SANs(サブジェクト代替名)とSNI(server_name indication),ワイルドカードの違い | SEの道標
◆SANsとSNIの違い
ここまで整理したところでSANsとSNIの違いをまとめてみましょう。
SANsは一枚のサーバー証明書で複数のドメインを管理できるもの
SNIは一台のサーバーで複数のサーバー証明書を使えるようにするもの
ということになります。
例えば、SANs証明証は高いのでドメインごとに個別で証明書を運用したいがグローバルIPを一つしか所有していない、といった場合はSNIを使用するわけです。
以上備忘でした。
