CN (PKI)

[3] Common Name (CN) は、 DN の属性型の1つです。

仕様書

[1] RFC 6125 - Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) (2015-03-13 22:27:53 +09:00 版) https://tools.ietf.org/html/rfc6125#section-1.8
[4] RFC 6125 - Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) (2015-03-13 22:27:53 +09:00 版) https://tools.ietf.org/html/rfc6125#section-2.3
[11] BR (2014-11-01 05:54:38 +09:00 版) https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf#page=17
[18] (2014-11-01 05:09:16 +09:00 版) https://cabforum.org/wp-content/uploads/EV-V1_5_2Libre.pdf#page=16

意味

[23] CN は、 DN が表す対象の名前を表します。 subject 欄なら subject name、発行者欄なら発行者の名前を表します。

[24] サーバー証明書では、サーバーのドメイン名を指定するのが普通です。

[25] CA証明書では CA の名前、クライアント証明書では利用者の名前を自然言語で記述することが多いようです。

構文

[20] 値は DirectoryString です。

[21] 次に示す通り、文脈により更に制約があります。

CN-ID

[2] CN-ID は、証明書の subject 欄の RDN であって、型が CN の attribute-type-and-value pair を丁度1つだけ含んでいて、その値がドメイン名全体であるものです >>1。

[8] 複数含まれる場合、どれを選択するべきかについて混乱があるため (RDN 参照)、除外されています >>4。

[9] しかし実際には CN-ID が複数含まれる証明書が使われているようです。 service identity を参照。

[5] 証明書の subject である application service は、 subject 欄により (CN-ID として) 記述することもできますし、 SAN により (DNS-ID、SRV-ID、URI-ID として) 記述することもできますし、その両方を使うこともできます。従来証明書は CN-ID によって CN に FQDN を記述する形を取ってきました。しかし CN はドメイン名だけでなく、人間可読な文字列を記述したり、ドメイン名の CN と人間可読な CN の両方を含めたりすることもできます。 >>4

[6] 例えば、 CN=A Free Chat Service,CN=im.example.org,O=Example Org,C=GB >>4 のような RDN もあり得ます。

[7] 従ってできるだけ CN-ID よりも SAN を使うべきです。しかし後方互換性その他の理由で CN-ID への対応を継続したい仕様は、そうしても構いません。 >>4

[10] 要件と処理方法については service identity も参照。

CA/Browser Forum による規定

[13] BR に従う CA が発行する証明書の subject 欄の CN では、値は FQDN (ワイルドカードFQDNを含む。) または IPアドレスを1つだけ指定したものでなければなりません >>11。

[16] その値は SAN の dNSName や iPAddress として指定したもののいずれかでなければなりません >>11。

[19] EV証明書では、ドメイン名を1つだけ指定したものでなければなりません。ワイルドカード証明書は認められていません。 >>18

[14] この欄は非推奨です (禁止はされていません) >>11, >>18。

[15] 必須では無いようです。

[17] 複数の CN を指定する可能性には言及がありません。

[12] BR に従う CA が発行する証明書では、 subject CN における内部名や予約済みIPアドレスの指定は2016年10月1日までに全廃することとなっています >>11。

メモ

[22] Mobile Creation | ソフトバンクモバイル (2014-08-29 10:51:46 +09:00 版) http://creation.mb.softbank.jp/mc/tech/tech_web/web_ssl.html

一部のSoftBank 3G携帯電話において、HTML中のURIのホスト部(FQDN)を大文字で記述した場合でも、HTTPリクエストは小文字にて行うものがあります。このため、ホスト部に大文字を使用した場合、SSL認証を行う際のcommon name(CN)との比較にて、正規の証明書と認識しないことがあります。
FQDNとCNを比較する際、大文字・小文字を区別するか否かはサーバ証明書のエンコード方式(データ型)に依存します。このため、サーバ証明書のCN属性値は小文字とするか、大文字・小文字を区別しない型であるPrintableStringで記述することを推奨します。

[26] 308330 - Remove support for common names in certificates; only support Subject Alt Names - chromium - Monorail ( (2017-05-22 19:08:45 +09:00)) https://bugs.chromium.org/p/chromium/issues/detail?id=308330

[27] 1245280 - don't fall back to subject common name for name information for new certificates ( (2017-05-22 19:12:24 +09:00)) https://bugzilla.mozilla.org/show_bug.cgi?id=1245280

[28] 700595 - Chrome no longer accepts certificates that fallback to common name (ERR_CERT_COMMON_NAME_INVALID) - chromium - Monorail ( (2017-05-22 19:15:23 +09:00)) https://bugs.chromium.org/p/chromium/issues/detail?id=700595&desc=2

[29] 1089104 - ssl_error_bad_cert_domain when subjectAltName extension is missing and Subject CN is encoded as TeletexString (2018-08-11 20:22:07 +09:00) https://bugzilla.mozilla.org/show_bug.cgi?id=1089104

[30] 308330 - Remove support for common names in certificates; only support Subject Alt Names - chromium - Monorail (2018-08-11 20:26:57 +09:00) https://bugs.chromium.org/p/chromium/issues/detail?id=308330