サーバ証明書の「名前」はどこに書かれる？SAN・dNSName・commonNameの違いを図で整理
サーバ証明書を勉強していると、subjectAltName（SAN）、dNSName、commonName（CN）という言葉が出てきます。
以前の私は、この3つを横並びの用語として覚えようとしていました。しかし、それだと「どれがどこにあるのか」が分からなくなり、何度も混乱しました。
そこで今回は、いきなり3つの用語から入るのではなく、まずサーバ証明書全体にはどんな情報が入っているのかを確認します。
そのうえで、証明書に含まれるさまざまな情報のうち、サーバの名前に関係する部分として、subjectAltName・dNSName・commonNameを整理します。
そもそもサーバ証明書には何が書かれている？
サーバ証明書は、単に「Webサイトの名前だけ」が書かれたファイルではありません。
X.509形式の証明書には、例えば次のような情報が含まれています。
誰が証明書を発行したかを表す情報
証明書の有効期間
証明書の対象を表す情報
サーバの公開鍵
用途や名前などを追加する拡張情報
証明書が改ざんされていないことを確認するための署名
細かな項目はほかにもありますが、初心者向けに大きくイメージすると次のようになります。
サーバ証明書
├─ 発行者や有効期間などの基本情報
├─ subject
│ ├─ 国
│ ├─ 組織名
│ └─ commonName（CN） ← 今回見る部分
├─ 公開鍵の情報
├─ extensions（拡張情報）
│ └─ subjectAltName（SAN） ← 今回見る部分
│ ├─ dNSName
│ ├─ iPAddress
│ └─ その他の名前形式
└─ 電子署名※実際のX.509証明書はもう少し細かな構造を持ちます。ここでは、今回の3用語の位置関係を理解しやすくするため簡略化しています。
こうして見ると、SAN・dNSName・commonNameは証明書そのものではなく、証明書に含まれる多くの情報の一部だと分かります。
今回注目するのは、上の図にある二つの枝です。
subject → commonName
extensions → subjectAltName → dNSNameこの位置関係を先に押さえると、3つの用語を整理しやすくなります。
最初に3つの関係を整理する
3つの違いを簡単にまとめると、次のようになります。
つまり、commonNameとdNSNameが同じ場所にあるわけではありません。
また、subjectAltNameとdNSNameも同じ意味ではありません。
commonNameとは
commonNameは「一般名」を意味し、CNと略されます。
証明書には、対象を表すsubjectというフィールドがあります。subjectには国や組織名など複数の属性を入れることができ、commonNameはその一つです。
例えば次のように表示されます。
subject:
C = JP
O = Example社
CN = www.example.com以前は、Webサーバの名前をcommonNameに入れ、接続先の名前確認に使う方法も広く利用されていました。
ただし、commonNameはDNS名専用の項目ではありません。
現在のDNS名確認では、後で説明するSAN側の情報を使うのが基本です。
subjectAltNameとは
subjectAltNameは「サブジェクト代替名」を意味し、SANと略されます。
名前にsubjectと入っていますが、subjectの中にある属性ではありません。
SANは、証明書のextensions、つまり拡張情報の中にある項目です。
SANには一種類の名前だけでなく、例えば次のような形式を格納できます。
dNSName：DNS名
iPAddress：IPアドレス
rfc822Name：メールアドレス
uniformResourceIdentifier：URI
私は、**SANは「いろいろな種類の名前を入れられる場所」**と考えると理解しやすくなりました。
dNSNameとは
dNSNameは、SANの中でDNS名を表す形式です。
例えば、一枚の証明書に次のような名前を持たせることができます。
subjectAltName:
dNSName = www.example.com
dNSName = shop.example.com
dNSName = api.example.comここで重要なのは、commonNameを三つ登録しているのではないという点です。
一つのsubjectAltNameの中に、dNSName形式の名前を複数登録していると考えます。
ではWebサイトの名前確認ではどこを見る？
現在の標準では、WebサイトのDNS名を確認するときは、SANに含まれるdNSNameを利用します。
例えば証明書の対象としてshop.example.comを表したい場合、そのDNS名がSAN内のdNSNameとして登録されます。
ここではブラウザが実際にどのタイミングで確認するのかまでは掘り下げません。
「証明書のどこを見るか」という構造だけなら、現在のDNS名確認では extensions → subjectAltName → dNSName が重要と覚えておけば十分です。
TLS通信の中でこの名前がどう使われるのかは、別の記事で整理しています。
現在の標準とIPA過去問は分けて考える
現在の標準では、サービスのDNS名確認にsubjectのcommonNameを使わず、SAN側の名前を利用する考え方になっています。
一方、古い仕様や実装では、SANにdNSNameがない場合にcommonNameを確認する方法もありました。
そのため、情報処理技術者試験の過去問では、
SANにdNSNameがあれば、それを確認する
dNSNameがなければcommonNameを確認する
という条件が問題文で指定されることがあります。
これは問題文の条件として解けばよく、現在の一般的なDNS名確認とは分けて考える方が混乱しません。
試験で迷ったら「二つの枝」を思い出す
3つの用語を横並びで暗記するより、私は次の二つの枝で覚えるようにしています。
subject
└─ commonName
extensions
└─ subjectAltName
└─ dNSNameこの形が頭に入っていれば、
「commonNameはSANの中だったかな？」
「SANとdNSNameは同じ意味だったかな？」
と迷いにくくなります。
まとめ
サーバ証明書には、発行者、有効期間、公開鍵、subject、extensions、署名など、さまざまな情報が入っています。
SAN・dNSName・commonNameは、その中の名前に関係する情報の一部です。
今回のポイントを整理すると、
commonNameはsubjectを構成する属性の一つ
subjectAltNameはextensions内にある拡張項目
dNSNameはsubjectAltName内でDNS名を表す形式
commonNameとdNSNameは証明書内の別の枝にある
subjectAltNameには複数のdNSNameを登録できる
現在のDNS名確認ではSAN側のdNSNameが重要
過去問では問題文に旧来のcommonName確認が指定されることがある
となります。
最初からSAN・dNSName・commonNameだけを見ると、似た言葉が並んでいるように感じます。
しかし、**「まずサーバ証明書全体があり、その中にsubjectやextensionsがあり、さらにその中にCNやSAN、dNSNameがある」**と上から順番に見ると、かなり整理しやすくなります。
