【図解】証明書のワイルドカード/SANs(サブジェクト代替名)/SNI の違いについて

サーバ証明書は正しく作成しないと、クライアントからhttps等のアクセスをする際にエラーが表示されてしまいます。

基本としてコモンネームと URL (FQDNホスト名)を一致させるように作ることが1つポイントとなりますが、今回の記事では、このコモンネームとURLに関する3つの仕組みの違いについて解説します。

1. ワイルドカード

コモンネームにワイルドカードを使うと、その表現に合致したURLを持つ複数のサーバに使い回すことができます。例えば Yahoo!JAPAN (https://www.yahoo.co.jp/) の証明書を見てみましょう。

Chrome の URL 左横の鍵マークをクリックし、「証明書」をクリックし、ポップアップした証明書の「詳細」タブをクリックすると、以下の画面が表示されます。

CN = *.yahoo.co.jp となっています。CN とは CommonName の略です。

このワイルドカード証明書は『.yahoo.co.jp』で終わる FQDN ホスト名(例えば www2.yahoo.co.jp や mail.yahoo.co.jp 等) のサーバであればどれにでも利用可能です。なので秘密鍵とセットでコピーして使いまわしができます。

2. SANs (Subject Alternative Names)

SANs とは『サブジェクト代替名』と訳され、コモンネームとは別に、URL として使うことを許された名前のことです。

例えば先ほどと同じように Google (https://www.google.co.jp/) にアクセスし、証明書を覗いてみます。

アクセス URL が www.google.co.jp、CN が *.google.com となっており合致しませんがエラーは表示されませんでした。なぜでしょうか?

実はこれはサブジェクト代替名で www.google.co.jp に合致するからです。

サブジェクト代替名はニュアンスとしてはそのWebサーバが複数の FQDN URL を持つ場合やテスト用に URL を変更する場合などに使われますが、ワイルドカードと同様、他のサーバへの転用目的でも使われます。

3. SNI (Server Name Indication)

バーチャルドメインを使って 1 つの IP アドレスで複数の https サイトを運用しているケースでは、クライアントからの https アクセス時に『どのサイトへアクセスしようとしているのか』という情報が無いと、サーバー側はどのサーバー証明書を提示して良いか分かりません。

SNI とは、クライアントが TLS セッション開始時の "Client Hello" メッセージにおいて "server_name" Extension を使ってサイト名をサーバに知らせる方法のことです。

以下に、このサイト(https://milestone-of-se.nesuke.com) にアクセスした際の Client Hello のパケットキャプチャを示します。

Extension: server_name の "Server Name" に本サイトの URL が示されていることが分かります。サーバー側はこの情報を見て、TLS Certificate において、どの証明書を提示するかを判断することができます。

他の2つ (ワイルドカード、SANs) と違い、SNI は証明書の作り方は関係ありません。また、クライアントとホストの両方で SNI に対応している必要があります。

フォローする