「サブジェクト別名（SAN）」とは何ですか？

サブジェクト代替名（SAN）とは、X.509証明書の拡張機能の一つであり、単一の「共通名（Common Name）」フィールドに加えて、その証明書が有効となるすべてのホスト名、IPアドレス、その他の識別情報を列挙したものです。最新のTLSクライアントやブラウザは、証明書の身元を「共通名」ではなくSANのエントリに基づいて検証するため、SANは事実上必須となっています。

主なポイント

• SANには、その証明書によって保護されているすべてのホスト名とIPアドレスが記載されています。
• TLSクライアントは、コモンネームではなく、SANエントリに基づいて身元を検証します。
• RFC 5280 では、SAN を標準の X.509v3 証明書拡張として定義しています。
• 1つの証明書には、さまざまな種類のSANエントリを複数含めることができます。
• Versa VMS証明書では、使用されるすべてのFQDNまたはIPアドレスに対してSANエントリが必要です。

このページの内容： その重要性 ・ 仕組み ・ 種類 ・ SAN およびVersa · よくある質問

SANはなぜ重要なのでしょうか？

何十年もの間、TLSクライアントは、証明書の識別情報を「共通名（CN）」という単一のフィールドと照合していました。これは、サーバーが1つのホスト名のみを使用している場合には機能しましたが、現代のインフラストラクチャでは、複数の名前（複数のホスト名）、ドメインとそのサブドメイン、あるいは複数のIPアドレスでアクセス可能なデバイスなど、負荷分散が行われることがほとんどです。SANは、1つの証明書が有効となるすべての識別情報を宣言できるようにすることで、この問題を解決しました。

この変化はセキュリティの面でも重要です。ブラウザやTLSライブラリは、身元照合において「共通名（Common Name）」を信頼することを、すでに数年前にやめています。Chromeは2017年にこれを非推奨とし、CA/Browser Forumの「Baseline Requirements」では、現在、公的に信頼されるすべての証明書に対してSANの記載が義務付けられています。SANエントリが一致しない証明書は、その共通名が何であれ、即座に検証に失敗します。今日、TLS証明書の発行やトラブルシューティングを行う際には、CNではなくSANを念頭に置く必要があります。

SANとは何ですか？

「Subject Alternative Name（サブジェクト代替名）」は、X.509v3公開鍵証明書を規定する標準規格であるRFC 5280で定義された証明書拡張機能です。これは証明書に付随するリストであり、各エントリにはタイプが指定されます。タイプには、DNS名（最も一般的）、IPアドレス、電子メールアドレス、およびその他あまり使用されないURIなどがあります。 1つの証明書には複数のエントリを含めることができます。通常は、プライマリドメイン、いくつかのサブドメイン、および1つ以上のIPアドレスが含まれます。

TLSクライアントが接続する際、接続先のホスト名またはIPアドレスをSANリストのすべてのエントリと照合します。いずれかのエントリと一致すれば十分であり、共通名（Common Name）が存在しても無視されます。認証局は発行前に各エントリの所有権を検証するため、既存の証明書にホスト名を追加する場合、その証明書のフィールドを直接編集するのではなく、リストを更新した状態で再発行することになります。

SANエントリの種類

RFC 5280 ではいくつかの SAN エントリタイプが定義されていますが、実際にはそのうちのごく一部が主流となっています。 DNS名 (dNSName) エントリは最も一般的であり、完全修飾ドメイン名によって証明書を識別します。先頭にワイルドカード（*.example.com) 1つのエントリでサブドメイン階層全体を網羅しています。 IPアドレス (iPAddress) 各エントリは、リテラルな IPv4 または IPv6 アドレスによって証明書を識別します。 メールアドレス そして URI これらのエントリは、S/MIME やその他の Web 以外の用途では見られますが、TLS の導入環境でははるかに稀です。

これらのタイプを基盤とする2つの導入パターンがあります。マルチドメイン（SAN/UCC）証明書は、1つの証明書に複数の無関係なドメインを記載するもので、組織が多数のサービスを運用しているものの、管理は1つの証明書で行いたい場合に役立ちます。ワイルドカード＋SAN証明書は、ワイルドカードエントリと、そのパターンに該当しないホストに対する明示的なエントリを組み合わせたものです。

SAN &Versa

Versa Versa の導入環境において、SANが最も明確に現れるのは、メッセージングサービス（VMS）の証明書です。VMSのインストールおよび設定を行う際、エージェントやVOSデバイスが使用するサーバー証明書、および内部データベース証明書を含むすべての証明書には、クラスタが応答する各FQDNまたはIPアドレス（管理インターフェース、エージェントトラフィック用のエラスティックインターフェース、およびサウスバウンドインターフェース）に対応するSANエントリが含まれている必要があります。自己署名スクリプトと、5～7個のSANエントリの入力を求めるCSRワークフローの両方で、この要件が強制されます。

高可用性クラスタでは、この要件がさらに厳しくなります。HAベースのVMS導入では、どのノードが応答しても証明書が有効であり続けるよう、各ノードのFQDNに加え、共有の弾力性FQDNに対するSANエントリが必要です。SANエントリ（多くの場合、後から追加された弾力性FQDN）が欠落していると、ネットワーク経路に問題がないにもかかわらずハンドシェイクが失敗し、接続障害を引き起こすことがよくあります。

よくある質問

SANと共通名（Common Name）の違いは何ですか？

「共通名（CN）」は、証明書の「サブジェクト」に含まれる単一の従来の識別子フィールドです。一方、SANは、DNS名やIPアドレスなど、複数の識別子を格納するリストです。最新のTLSクライアントは、SANに対してのみ検証を行います。CNは、たとえ値が入力されていても、識別子の照合においては無視されます。

証明書にSANが含まれていても、共通名（Common Name）がないことはありますか？

はい。CA/Browser Forumの「Baseline Requirements」では、SANが存在する限り、Common Name（CN）が空であるか、あるいは存在しない証明書も許可されています。また、現在では一部の認証局がデフォルトでCNを省略しています。身元確認にはSANだけで十分であり、もはやCNに依存する要素は一切ありません。

なぜブラウザは「共通名」を信頼しなくなったのでしょうか？

「共通名（Common Name）」に依存していたため、異なるTLSライブラリ間で曖昧さや解析の不一致が生じ、攻撃者はこれを悪用して偽装証明書を取得していました。Chromeは2017年にCN照合を非推奨とし、その後、CA/Browser Forumは業界全体において、すべての公的に信頼される証明書に対してSANの使用を義務付けました。

アクセスしようとしているホストに対するSANエントリが証明書にない場合、どうなるのでしょうか？

TLSハンドシェイクの検証に失敗します。Common Nameが一致している場合や、証明書自体が有効である場合でも、クライアントやブラウザは「名前不一致」エラーを理由に接続を拒否します。この問題を解決するには、欠落しているホスト名をSANリストに追加して、証明書を再発行する必要があります。

1つの証明書のSANリストに、DNS名とIPアドレスの両方を含めることはできますか？

はい。1つのSANリストには、DNS名、IPアドレス、電子メールアドレス、URIといった異なる種類のエントリを混在させることができます。ただし、各エントリが発行元である認証機関によって検証されていることが条件です。双方向でアクセス可能なインフラストラクチャでは、DNSエントリとIPエントリを混在させることは一般的です。

SANに関する詳細

さらに詳しく知りたい場合は、私たちが信頼している情報源を以下にご紹介します。

関連用語

SANについてお読みの方は、次にこれらもぜひチェックしてみてください。