SNIとは

詳細な図解

SNIを読むときの前提

SNI（Server Name Indication）は、TLS接続時にクライアントが接続したいホスト名をサーバーへ伝える仕組みです。1つのIPやロードバランサーで複数の証明書を出し分けるために使われます。

実務では、SNI名、返却証明書、SAN、既定証明書、古いクライアント、CDN/LB/WAFの終端点差分を確認します。

証跡には、接続先FQDN、SNI有無、返却証明書、SAN、TLS終端点、IPアドレス、確認コマンド、確認時刻を残します。

返る証明書を名前で確認する

TLS終端点は、SNIで受け取った名前に応じて証明書を選びます。SNIを指定せずに確認すると、既定証明書が返り、実利用時と違う結果になることがあります。

証明書更新や障害調査では、対象FQDNをSNIとして指定して確認します。curlやopensslでSNIを付けるかどうかが切り分け結果に影響します。

• SNI付きで接続して証明書を確認する。
• SNIなしの場合の既定証明書も確認する。
• 確認コマンドを証跡に残す。

古いクライアントと互換性

古いクライアントや一部の組み込み機器はSNIに対応していない場合があります。その場合、名前に対応した証明書ではなく既定証明書が返り、SAN不一致になることがあります。

利用者の一部だけTLS警告になる場合、端末やライブラリがSNIを送っているかを確認します。業務上必要なら専用IPや既定証明書の調整を検討します。

• 失敗クライアントがSNI対応か確認する。
• 既定証明書のSANを確認する。
• 専用終端点が必要か判断する。

CDNやLBのルールを見る

CDN、ロードバランサー、WAF、リバースプロキシでは、SNI、Hostヘッダー、ルーティングルール、証明書マッピングが別々に設定されることがあります。

SNIでは正しい証明書が返っても、Hostヘッダーやオリジン設定が違うとアプリは別サイトへ流れます。TLSとHTTPの名前を分けて確認します。

• SNIとHostヘッダーの違いを確認する。
• 証明書マッピングとルーティングを突合する。
• CDN/LBの片系差分を確認する。

変更証跡と引き継ぎ

SNI対応では、対象FQDN、TLS終端点、証明書マッピング、既定証明書、確認コマンド、利用者影響を残します。証明書ファイルだけでは名前出し分けの証跡になりません。

引き継ぎでは、Web基盤担当、CDN/LB管理者、アプリ所有者、関連語としてSAN、証明書チェーン、TLS、FQDNを残すと確認しやすくなります。

• SNI別の返却証明書を記録する。
• 既定証明書と例外条件を残す。
• 証明書更新時の確認観点へ追加する。

関連語

同じ主要カテゴリの用語

セキュリティ・認証の学習順

同じ主要カテゴリの用語をまとめて確認できます。現在の用語を起点に、前後の用語へ進むと文脈を保ったまま読み進められます。

InfraEngKit内の関連機能