HTTPS接続におけるサーバ認証で、CommonName（CN）からSubject Alternative Name（SANs）への変更はなぜ行われたのでしょうか？この記事では、その背景にある理由や、変更の重要性についてわかりやすく解説します。
CommonName（CN）からSANsへの変更の背景
HTTPSのSSL/TLS証明書には、サーバを識別するためにドメイン名が記載されています。従来、証明書にはCommonName（CN）フィールドが使われていましたが、近年、Subject Alternative Name（SANs）フィールドが推奨されています。この変更には、セキュリティの向上や柔軟性の確保が関係しています。
CommonName（CN）は、証明書に記載されるドメイン名を一つだけ指定するため、複数のサブドメインを持つサイトにとって不便な点がありました。これに対して、SANsは複数のドメイン名をサポートするため、より多くのユースケースに対応できるようになりました。
セキュリティの観点からSANsが優れている理由
SANsを使用することで、より強固なセキュリティが確保できます。従来のCNを使った方法では、証明書に記載された一つのドメイン名のみが保証されていましたが、SANsでは複数のドメインを一つの証明書でカバーできるため、ドメイン検証が一貫して行われ、セキュリティリスクが減少します。
さらに、SANsを使用することで、証明書の検証時に全ての関連ドメインが正確に検証されるため、偽装サイトなどからの攻撃を防ぎやすくなります。この変更は、現代のインターネットセキュリティの強化に寄与しています。
SANsの利点：複数のドメインのサポート
SANsを使用すると、1つの証明書で複数のドメインをカバーできるため、管理の簡略化やコスト削減が可能です。例えば、異なるサブドメインや異なるドメイン名を持つウェブサイトでも、1つの証明書で対応することができ、証明書の更新作業が一元化されます。
また、SANsは、企業が様々なサービスを提供する際に役立ちます。例えば、オンラインショッピングサイトが複数のドメイン（www.shop.com, secure.shop.com, api.shop.com）を持っている場合、これらを全て1つの証明書で保護できるため、管理が効率的になります。
わざわざSANsに変える必要があったのか？
この変更は、従来の方式に比べて技術的な進化を反映しています。CommonName（CN）で1つのドメイン名のみを指定する方法では、現在の多様なインターネット環境には対応しきれませんでした。そのため、SANsへの変更は、インターネットの進化に伴い必要なステップだったのです。
SANsは、現代のウェブサイトが抱える複数ドメインやサブドメイン、さらには異なるサービスを適切にカバーするために不可欠な技術となり、ウェブサイトのセキュリティと管理を大幅に向上させることができます。
まとめ
HTTPSにおけるサーバ認証でCommonNameからSANsに変更された理由は、セキュリティの強化や複数ドメインへの対応が必要だったためです。SANsを使用することで、より多くのドメインを一元的に管理でき、セキュリティ面でも大きな利点があります。この変更は、インターネットの進化と共に求められるものであり、今後のセキュリティ標準においても重要な役割を果たします。
コメント