SANとは

詳細な図解

SANを読むときの前提

SAN（Subject Alternative Name）は、証明書が有効なDNS名やIPアドレスを記載する項目です。TLSクライアントは接続先名がSANに含まれるかを確認します。

実務では、証明書を発行する前に、利用者が接続するFQDN、API名、CNAME、ワイルドカード、内部外部の名前差分、SNIで選ばれる証明書を確認します。

証跡には、対象FQDN、SAN一覧、ワイルドカード範囲、接続元、CNAME先、証明書フィンガープリント、確認コマンド、確認時刻を残します。

CNではなくSANを見る

古い手順ではCNを重視する説明が残っていることがありますが、実際の名前検証ではSANが重要です。CNに名前があってもSANに無ければTLS警告になることがあります。

証明書更新時は、旧証明書のSANをコピーするだけでなく、廃止した名前や追加したAPI名がないかを確認します。不要なSANは露出情報にもなります。

• 接続先名がSANに含まれるか確認する。
• 旧証明書との差分を確認する。
• 不要なSANを削除する。

ワイルドカードとCNAMEの範囲

ワイルドカード証明書は便利ですが、通常は1階層分の名前だけを対象にします。たとえば *.example.com は a.example.com には使えても、a.b.example.com には使えないことがあります。

CNAMEを使う場合でも、証明書で検証されるのは利用者が接続した元の名前です。CNAME先の名前だけ証明書に入れても、元のFQDNがSANになければ失敗します。

• ワイルドカードの階層範囲を確認する。
• CNAME元の接続名をSANに入れる。
• 内部名と公開名の混在を避ける。

SNIと終端点差分を確認する

同じIPやロードバランサーで複数証明書を扱う場合、SNIにより返る証明書が変わります。SANの確認は、実際のSNI名で接続して行います。

CDN、LB、WAF、リバースプロキシの片系だけ古い証明書を返すことがあります。SAN不足に見える障害でも、実際はSNIや終端点差分が原因の場合があります。

• SNI付きで証明書を取得する。
• 全TLS終端点のSANを比較する。
• 既定証明書が返る条件を確認する。

変更証跡と引き継ぎ

SAN対応では、対象サービス、接続名一覧、証明書のSAN、申請理由、不要名の削除判断、確認結果を残します。名前の一覧はアプリ、DNS、証明書、監視でずれやすいです。

引き継ぎでは、Web基盤担当、DNS管理者、アプリ所有者、関連語としてCSR、SNI、証明書、FQDNを残すと確認しやすくなります。

• 実利用FQDNを一覧化する。
• 証明書SANとDNS台帳を突合する。
• 追加削除の判断理由を残す。

関連語

同じ主要カテゴリの用語

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

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

InfraEngKit内の関連機能