SAN（Subject Alternative Name）とは？
SAN（Subject Alternative Name）は、TLS/SSL証明書の一部で、証明書が適用されるドメインやサブドメインを複数指定できる拡張フィールドです。もともと証明書は1つのドメイン名に対してのみ発行されるのが一般的でしたが、SANの導入により、1枚の証明書で複数のドメインやサブドメインをカバーできるようになりました。たとえば、example.com や www.example.com に加え、mail.example.com なども同じ証明書で保護したい場合、それぞれをSANに記載しておけば、1枚の証明書でこれら全てを安全にサポートできます。
SANの設定は、サイトのセキュリティを確保しつつ、ドメインやサブドメインの管理をシンプルにするための重要な要素で、GoogleやAppleといった大手も含め、インターネット全体で推奨されています。
SANが存在する場合、CNは無視される点
かつて、証明書の対象ドメイン名はCommon Name（CN）フィールドに記載されていましたが、SANが存在する場合、証明書の検証プロセスにおいてはSANフィールドが優先されます。RFC 2818に従い、SANが設定されている証明書ではCNフィールドは参照されず、SANに記載されたドメイン名が唯一の検証対象とされます。これは、SANの利用が証明書の柔軟性やセキュリティ面での利点をもたらすためです。
RFC2818の原文が下記にあります。
If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead.
https://datatracker.ietf.org/doc/html/rfc2818
dNSName型のsubjectAltName拡張が存在する場合、それをIDとして使用しなければならない。
そうでない場合は、証明書のサブジェクトフィールドの(最も具体的な) 共通名フィールドを使用しなければならない。Common Nameの使用は既存の方法であるが、非推奨であり、認証局は代わりにdNSNameを使用することが推奨される。
ブラウザの挙動とセキュリティ要件
現代のブラウザは、SANが含まれる証明書では、SANに記載されたドメイン名のみを対象として証明書の有効性を確認します。例えば、SANにexample.comとwww.example.comが記載されている証明書では、sub.example.comやtest.example.comには証明書の保護が適用されません。SANに含まれていないドメイン名でのアクセスは証明書エラーが表示されるため、保護されない通信と判断され、ユーザーに警告が表示される場合もあります。
こうした挙動は、Webブラウザがユーザーに対するセキュリティ警告を適切に行うことで、悪意あるサイトから保護するために必要な対策とされています。そのため、SANに対象ドメインをすべて明示的に記載することが、ブラウザ上でのエラーを避けるために不可欠です。
SAN設定の重要性
SANの設定は、証明書の有効範囲を明確にするために重要です。特に、複数のサブドメインやドメインで同一証明書を利用する場合、必要なすべてのドメイン名をSANに含めておくことで、証明書エラーやブラウザの警告表示を避けられます。また、SANにはワイルドカードを含めることもできるため、*.example.comを記載することで、sub.example.comやblog.example.comなどの複数サブドメインを1つの証明書で包括的に保護することが可能です。
SANの設定が不適切である場合、サブドメインでのアクセス時に「保護されない通信」と表示されたり、警告が表示される原因となります。これによりユーザーの信頼が損なわれるリスクがあるため、適切なSANの設定が欠かせません。
CNにワイルドカードを用い、SANに通常ドメインを記載している場合
証明書のCNフィールドにワイルドカード（例：*.example.com）を設定し、SANには特定のドメイン（例：example.comやwww.example.com）を記載している場合、SANフィールドが優先され、CNフィールドのワイルドカードは無視されます。つまり、SANに含まれていないサブドメイン（例えばsub.example.com）には証明書の保護が適用されないため、アクセスすると「保護されていない通信」と判断される可能性があります。このため、ワイルドカードを使用する場合も、保護したいドメイン名をすべてSANに記載するか、SANにワイルドカードを含めることが重要です。
