インディケーション、サーバ名表示)は、SSL/TLSの拡張仕様の一つである。SSLハンドシェイク時にクライアントがアクセスしたいホスト名を伝えることで、サーバ側がグローバルIPごとではなくホスト名によって異なる証明書を使い分けることを可能にする。1.1の名前ベースバーチャルホストをHTTPSに対応させるために使われる。SNIを機能させるには、Webサーバ側とブラウザ側両面の対応が必要である。SNIを実装しないブラウザでは全てのホスト名で同じサーバ証明書が使われるため、警告が表示されることがある。2016年時点でPC・モバイルの主要なブラウザで問題なく利用できる状況である。外部リンク問題の背景[編集]SSL/TLS接続のはじめに、クライアントはSSL/TLSのサーバから(サーバとCAの)証明書を受け取り、証明書の改ざんされていないことなどを確認する。サーバ証明書にはホスト名が書かれており、それが今接続しようとしているホスト名と一致することをクライアントは確認する。ない場合、なりすましや中間者攻撃の恐れがあるため、クライアントはユーザに警告をする。ユーザの責任で証明書を信用し、警告を迂回することができるアプリケーションも存在する。HTTPの場合、名前ベースバーチャルホストを使うと、複数のホスト名(同一のドメインであれ、異なるドメインであれ)を単一のサーバと単一のグローバルIPで運用できる。これは、ブラウザ側がHTTPヘッダによって希望のホスト名を指定することで働く。HTTPSの場合、HTTP要求をやりとりする前にSSL/TLSハンドシェイクを行う必要がある。このため、ブラウザがどのホストを訪問するかを、ハンドシェイク時点でサーバ側には予測できず、HTTPヘッダのホスト名によって複数枚のサーバ証明書を使い分けることができない。したがって、単一のサーバで複数枚のサーバ証明書を使い分けるには名前ベースバーチャルホストは利用できず、ホスト名ごとに異なるグローバルIPを使う必要があった(IPベースバーチャルホスト)。この問題への対処方法として、1枚のサーバ証明書に複数のホスト名を指定する手段が知られていた。v3の証明書で導入されたsubjectAltName拡張を利用することで、追加のホスト名を指定できる。Name属性同様、こちらでもワイルドカードを使える。実運用においてサーバの運用する全てのホスト名を予めCSRに含めておくことは現実的ではなく、ホスト(ワイルドカードの場合、ドメイン)名が増えるたびに別々にサーバ証明書を導入することが多い。2005年から、CAcertはTLSをバーチャルホスト下で使う方法について様々な実験を行なった[1]が、多くは非実用的なものだった。subjectAltName拡張を使って運用する全ドメインのホスト名を1枚のサーバ証明書に集約し、ドメインが増えたりドメイン名が変わったりするごとに取得しなおすという方法[2]が提案された。これらの事情によって、複数のサーバ証明書を使い分けたいサーバは、単数または少数のホスト名をIP別に運用することが要求される。ホスト(ワイルドカードの場合、ドメイン)名ごとに別のグローバルIPを取得することはコストがかかる(IPアドレス枯渇問題)ため、多くのWebサイトにはHTTPS通信の利用はハードルが高かった。Indication(SNI)では、TLSに拡張を加えることでこの問題に対処する。TLSのハンドシェイク手続きで、HTTPSクライアントが希望するドメイン名を伝える(この部分は平文となる)[3]。それによってサーバが対応するドメイン名を記した証明書を使うことが可能になる。サーバとクライアントが共にSNIに対応していれば、一つのIPで複数のドメインにHTTPSサーバを提供することが可能になる。3546「TLS拡張仕様」に加わった。esni[編集]esniとは暗号化(Encrypted)されたSNIである。対応状況[編集]SNIに対応するには、アプリケーションの使うSSLライブラリがホスト名を受け取る仕組みが必要である。OSの機能を利用してSSL通信を行うアプリケーションでは、OSのSSL機能がSNIをサポートしない場合はSNIを使うことはできない。2011年の時点でほとんどのブラウザやSSLライブラリはSNIを実装したが、ユーザの使うOSとの組み合わせによってはSNIを利用できない場合がしばしばある。対応ソフト[編集]2004年に、OpenSSLでTLS/SNIをサポートするパッチがEdelKeyプロジェクトによって作成された[4]。0.9.8にポートされた。