935.txt

[82] [[TLS]] を使う多くの[[プロトコル]]では、[[サーバー証明書]]に示された[[ドメイン名]]と[[利用者]]が指定した[[ドメイン名]]が一致しているかの検査
([DFN[[[service identity]]]] の検査) を行うことが求められています。

[83] この検査は、[[利用者]]が指定した通りの[[サーバー]]に接続していることを確かめるためのものです。
この検査を通過しない場合には、 ([[サーバー]]の設定に誤りがあるのでなければ)
[[MITM]] 攻撃により偽の[[サーバー]]に接続している可能性があります。

* 仕様書

[REFS[
- [1] '''[CITE@en[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)]] ([TIME[2015-03-13 22:27:53 +09:00]] 版) <https://tools.ietf.org/html/rfc6125>'''
-- [4] [CITE@en[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)]] ([TIME[2015-03-13 22:27:53 +09:00]] 版) <https://tools.ietf.org/html/rfc6125#section-3>
-- [11] [CITE@en[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)]] ([TIME[2015-03-13 22:27:53 +09:00]] 版) <https://tools.ietf.org/html/rfc6125#section-4>
-- [26] [CITE@en[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)]] ([TIME[2015-03-13 22:27:53 +09:00]] 版) <https://tools.ietf.org/html/rfc6125#section-5>
-- [33] [CITE@en[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)]] ([TIME[2015-03-13 22:27:53 +09:00]] 版) <https://tools.ietf.org/html/rfc6125#section-6>
-- [67] [CITE@en[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)]] ([TIME[2015-03-13 22:27:53 +09:00]] 版) <https://tools.ietf.org/html/rfc6125#section-7.1>
-- [69] [CITE@en[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)]] ([TIME[2015-03-13 22:27:53 +09:00]] 版) <https://tools.ietf.org/html/rfc6125#section-7.4>
-- [72] [CITE@en[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)]] ([TIME[2015-03-13 22:27:53 +09:00]] 版) <https://tools.ietf.org/html/rfc6125#appendix-A>
- [2] [CITE[RFC Errata Report]] ([TIME[2015-03-24 22:54:51 +09:00]] 版) <http://www.rfc-editor.org/errata_search.php?rfc=6125>
- [151] [CITE@en[RFC 2818 - HTTP Over TLS]] ([TIME[2014-12-15 14:10:09 +09:00]] 版) <http://tools.ietf.org/html/rfc2818#section-3>
- [168] [CITE[RFC Errata Report]] ([TIME[2015-03-04 17:58:35 +09:00]] 版) <http://www.rfc-editor.org/errata_search.php?rfc=2818>
]REFS]

[3] [[RFC 6125]] は [[TLS]] と [[PKIX]] を用いる場合で、[[アプリケーションプロトコル]]においてサービスの識別に[[ドメイン名]]を使う場合に、
その service identity の検査をどう行うべきかを規定するものです。従来 [[TLS]]
を用いる[[アプリケーションプロトコル]]はそれぞれ検査の方法を規定していましたが、
ほぼ同じで細部が異なるものでした。 [[RFC 6125]] はそれを踏まえて新たに標準的な方法を規定するものです。
ただし従来の各プロトコルの規定を廃止するものではなく、新プロトコルや既存プロトコルの改訂版で明示的に参照される場合にのみ適用する [SRC[>>1]] とされています。

[73] [[RFC 6125]] の附属書A、B はそれまでに出版された [[IETF]] の仕様書の
[[service identity]] の検査に関する条項をまとめています。

* ドメイン名

[24] [[証明書]]には[[ドメイン名]]は色々な形で記述され得ます。そのうち
[[RFC 6125]] に従う仕様で [[service identity]] を表すものとして解釈されるのは、
[FIG(short list)[
- [[CN-ID]]
- [[DNS-ID]]
- [[SRV-ID]]
- [[URI-ID]]
]FIG]
... の4つの[[識別子型]]の識別子です。 (それ以外も用いることも排除はされていません。)

[25] これらの形式の値の一部または全部が [[DNSドメイン名]]とみなされます。
[[IDN]] は [[Aラベル]]を使った [[ASCII]] のみの形に変換されてから[[証明書]]に記述されます。

* IP アドレス

[74] [[証明書]]では[[IPアドレス]]は [[SAN]] の [CODE[[[iPAddress]]]]
に記述されます。

[75] [[HTTPS]] などいくつかの仕様は [[IPアドレス]]の場合に [CODE[[[iPAddress]]]]
を検査するべきことを規定しています。それ以外の仕様は (意図的かどうかは不明ですが)
明記していません。 [[RFC 6125]] も[[ドメイン名]]のみが適用対象であるとして
[[IPアドレス]]には言及していません。

[80] 古い仕様は [CODE[[[CN]]]] で [[DNSドメイン名]]のみならず
[[IPアドレス]]を使えるとするものもあるようです。

* 証明書

[12] [[CA]] が[[完全修飾DNSドメイン名]]に基づく[[証明書]]を発行する時は、
次の規則が適用されます [SRC[>>11]]。
[FIG(list)[
- [13] [[証明書]]は [[DNS-ID]] を含む[['''べきです''']]。
- [14] [[証明書]]を使用する[[応用サービス]]の仕様が要求しているなら、
[[SRV-ID]] を含む[['''べきです''']]。
- [15] [[証明書]]を使用する[[応用サービス]]の仕様が要求しているなら、
[[URI-ID]] を含む[['''べきです''']]。
-- [16] [[URI-ID]] の [[scheme]] は当該サービスのプロトコルの [[scheme]] でなければ[['''なりません''']]。
-- [17] [[URI-ID]] の [[host]] (またはそれに相当するもの) は当該サービスの[[完全修飾DNSドメイン名]]でなければ[['''なりません''']]。
- [19] [[証明書]]は [CODE[[[XmppAddr]]]] など応用依存の識別子も含んで構いません。
- [20] [[証明書]]を使用する[[応用サービス]]の仕様が明示的に[RUBYB[推奨]@en[encourage]]する場合を除き、
[[CN-ID]] を含む[['''べきではありません''']]。
- [21] [[DNS-ID]]、[[SRV-ID]]、[[URI-ID]] は複数あっても構いません。
- [23] [[証明書]]を使用する[[応用サービス]]の仕様で認められる場合を除き、
[[DNSドメイン名]]に[[ワイルドカード]]を含める[['''べきではありません''']]。
]FIG]

[22] [[CN-ID]] が複数ある[['''べきではない''']] [SRC[>>11, >>69]] とされていますが、
定義上複数あるものは [[CN-ID]] ではありません。実際には [[SNI]] に対応していない環境に向けても
[[virtual host]] を実現するために複数の [[CN-ID]] を[[証明書]]に含めることがある
[SRC[>>69]] ようです。

;; [70] ですから、 [[CN-ID]] の定義が誤っていると解釈するべきでしょう。

* CSR

[27] [[CSR]] を作成するサービス提供者に対しては次のような指針が示されています [SRC[>>26]]。
[FIG(list)[
- [28] 一般に、[[証明書]]を使用する[[応用サービス型]]について要求または推奨されるすべての[[識別子型]]の[[識別子]]を含めることが[RUBYB[推奨]@en[encourage]]されます。
- [29] [[証明書]]が任意の[[応用サービス型]]について利用され得る場合は、
[[DNS-ID]] のみ含めることが推奨されます。
- [30] [[証明書]]が特定の[[応用サービス型]]についてのみ利用される場合は、
[[DNS-ID]] と、 (あれば) 当該[[応用サービス型]]に限定される [[SRV-ID]] や [[URI-ID]]
を含めることが推奨されます。
- [31] 複数の[[応用サービス型]]を提供したい時で [[SRV-ID]] や [[URI-ID]]
で適用対象を限定したい時は、複数の[[証明書]]を求めることが推奨されます。
異なる[[応用サービス型]]に関する複数の [[SRV-ID]] や [[URI-ID]]
を含む[[証明書]]を求めることは[RUBYB[推奨されません]@en[discouraged]]。
-- [32] [[IMAP]] と [[POP]] のような同種の[[プロトコル]]群はここでいう「複数の[[応用サービス型]]」には該当しません。
]FIG]

* アプリケーションプロトコル

[5] [[アプリケーションプロトコル]]の設計では、次の点を考慮するべきです [SRC[>>4]]。
[FIG(list)[
- [6] [[DNS]] [CODE[[[SRV]]]] [[レコード]]を使って[[ドメイン名]]の[[解決]]を行うなら、
[[証明書]]で [[SRV-ID]] [[識別子型]]への対応を要求または推奨することを検討するべきです [SRC[>>4]]。
- [7] [[URI]] を使って応用サービスを識別するなら、[[証明書]]で [[URI-ID]] 
[[識別子型]]への対応を要求または推奨することを検討するべきです [SRC[>>4]]。
-- [18] [[URI-ID]] の [[URL scheme]] を規定しなければ[['''なりません''']] [SRC[>>11]]。
- [8] [[後方互換性]]のために[[証明書]]の [CODE[[[CN]]]]
欄の[[DNSドメイン名]]を使う必要があるなら [[CN-ID]]
[[識別子型]]にフォールバックとして対応することを推奨することを検討するべきです [SRC[>>4]]。
- [9] [[DNSドメイン名]]で[[ワイルドカード]]に対応する必要があるなら、
[[ワイルドカード証明書]]への対応を推奨すること、
[[DNSドメイン名]]のどこに[[ワイルドカード]]文字が認められるか規定することを検討するべきです
[SRC[>>4]]。
]FIG]

;; [10] しかし既存のアプリケーションは [[SRV-ID]] や [[URI-ID]] に対応していないものが多い
[SRC[>>4]] です。

* 検証

[34] [[アプリケーションプロトコル]]の[[クライアント]]は、 [[service identity]]
を次のようにして[RUBYB[検証]@en[verify]]します [SRC[>>33]]。
[FIG(steps)[
= [35] [[利用者]]の入力等に基づき、受け入れる[[参照識別子]]のリストを作成します。
= [36] [[サーバー証明書]]から[[サーバー]]の識別子を得ます。
= [37] [[参照識別子]]と[[サーバー]]の識別子が一致するか検査します。
]FIG]

[55] [[証明書]]に示された[[識別子]]を順に調べ、
[[参照識別子]]のリストとの一致を検査します。一致するものが見つかれば、
そこで探すのをやめる[['''べきです''']]。 [SRC[>>33]]

[56] [[証明書]]に [[DNS-ID]]、[[SRV-ID]]、[[URI-ID]]、応用依存の ([[クライアント]]が対応する)
[[識別子型]]の[[識別子]]が含まれているなら、 [[CN-ID]] の[[参照識別子]]との一致を調べては[['''なりません''']]。
含まれていないなら、フォールバックとして [[CN-ID]] の一致を検査して構いません。 [SRC[>>33]]

;; [81] 古い仕様は [[DNS-ID]] があっても [[CN-ID]] を検査することを認めていたものもあるようです。

;; [71] [[RFC 6125]] は[[ドメイン名]]を対象にしているので[[応用サービス型]] 
([[URL scheme]]) と[[ドメイン名]]にしか言及がありませんが、 [[URI-ID]] に
[[path]] や [[query]] が含まれる場合や、 [[URI-ID]] 相当のものが[[ドメイン名]]を含まない場合についても[[アプリケーションプロトコル]]はどう比較するか規定しなければならないものと思われます。

** 参照識別子のリストの作成

[38] [[クライアント]]は、[[参照識別子]]のリストを作成しなければ[['''なりません''']]
[SRC[>>33]]。

[52] まず[[利用者]]の入力や設定、[[ハイパーリンク]]などによって指定された接続先情報から、
[[ドメイン名]]の情報と[[応用サービス型]]を得ます [SRC[>>33]]。

[EG[
[39] 例えば入力 [[URL]] [CODE[[[sips:alice@example.net]]]] から、
[[応用サービス型]] 「sip」と[[ドメイン名]] 「example.net」を得ます [SRC[>>33]]。
]EG]

[53] これは入力に直接含まれる情報を取り出すだけかもしれませんし、
何らかの解決サービスに問い合わせた結果かもしれません。
ただし攻撃者が介在し得ない安全な方法で得たもの ([[利用者]]が明示的に指定したもの、
[[DNSSEC]] により得たものなど) でなければ[['''なりません''']] [SRC[>>33]]。
入力に直接由来する[[ドメイン名]] ([[source domain]]) を使う[['''べき''']]で、
それを [[DNS]] [[解決]]するなどして得られた[[ドメイン名]] ([[derived domain]])
を使う[['''べきではありません''']] [SRC[>>33]]。

;; [40] これは、利用者の入力とサーバー側が示した識別子が一致することをもってのみ、
当該[[証明書]]によって安全が保たれると言えるからです。
ただし例外として、人間利用者が[[証明書]]を他のドメイン名に「pin」
した場合には、 [[source domain]] と他のドメイン名の両方を含むことになります。 [SRC[>>33]]

[54] 次に、[[ドメイン名]]と[[応用サービス型]]から、[[参照識別子]]のリストを得ます。

[FIG(list)[
- [41] [[DNS-ID]] を含める[['''べきです''']]。 [SRC[>>33]]
-- [[DNSドメイン名]]のみで、[[応用サービス型]]は含まれません [SRC[>>33]]。
- [42] 当該[[応用サービス型]]でサーバーが通常 [[DNS]] [CODE[[[SRV]]]] 
[[レコード]]により発見可能なものなら、 [[SRV-ID]] を含む[['''べきです''']]。 [SRC[>>33]]
-- [[SRV-ID]] は [CODE[_]]、[[応用サービス型]]、[CODE[.]]、[[DNSドメイン名]]で構成されます。
- [43] 当該[[応用サービス型]]が通常セキュリティー目的で [[URI]]
に関連付けられるものなら、 [[URI-ID]] を含む[['''べきです''']]。 [SRC[>>33]]
-- [[URI-ID]] は[[応用サービス型]]と[[DNSドメイン名]]に相当するものが含まれます。
- [44] [[後方互換性]]のため [[CN-ID]] を含むことができます。 [SRC[>>33]]
-- [[DNSドメイン名]]のみで、[[応用サービス型]]は含まれません [SRC[>>33]]。
- [47] [CODE[[[CN]]]] 以外の [[RDN]] について識別子を構築し、検査しては[['''なりません''']]
[SRC[>>33]]。
- [50] [CODE[[[XmppAddr]]]] のような[[応用サービス型]]依存の識別子を含めることもできます。
]FIG]

;; [51] この[[参照識別子]]のリストの作成は、[[サーバー]]側が示す識別子とは独立に、
[[クライアント]]側のみで行わなければ[['''なりません''']] [SRC[>>33]]。

[45] どの[[識別子型]]の識別子を含めるかは [[local policy]] の問題です。
例えば特定のサービスにのみ接続するよう構築されたクライアントでは、
その[[応用サービス型]]の [[SRV-ID]] のみ含めることにできます。
より一般的なクライアントでは [[SRV-ID]] と [[DNS-ID]] の両方を含めます。
当面の間は [[CN-ID]] にも対応する必要がある可能性が高いです。
[SRC[>>33]]

[76] [[CN-ID]] が複数ある場合は定義上 [[CN-ID]] とは言わないはずですが、
実際には複数含まれた[[証明書]]も存在しています (>>22)。 [[RFC 6125]]
の定義通りに処理するなら、複数ある場合には[[資源識別子]]のリストには含めないことになります。
[[HTTPS]] などいくつかの仕様は、どれを選ぶべきかを規定しています ([[HTTPS]]、[[RDN]] 参照)。

[EG[
[48] [[Webブラウザー]]は、  [CODE[www.example.com]] の [[HTTPS]] において 
[FIG(list)[
- [[DNS-ID]] [CODE[www.example.com]]
- フォールバック [[CN-ID]] [CODE[www.example.com]]
]FIG]
... を含めることができます [SRC[>>33]]。
]EG]

[EG[
[49] [[MUA]] は、 [[IMAPS]] [CODE[example.net]] が
[CODE[mail.example.net]] に解決される時、
[FIG(list)[
- [[SRV-ID]] [CODE[_imaps.example.net]]
- [[DNS-ID]] [CODE[example.net]]
- [[DNS-ID]] [CODE[mail.example.net]]
- フォールバック [[CN-ID]] [CODE[example.net]]
- フォールバック [[CN-ID]] [CODE[mail.example.net]]
]FIG]
... を含めることができます [SRC[>>33]]。
]EG]

;; [46] これらの識別子は[[証明書]]に示された識別子と比較するために用意するだけで、
実際に [[ASN.1]] のような[[証明書]]で使われる表現で構築する必要はありません。 [SRC[>>33]]

** ドメイン名の比較

[57] [[クライアント]]は、[[参照識別子]]の[[DNSドメイン名]]部分が[[一致]]するか検査しなければ[['''なりません''']]。
[[参照識別子]]の[[DNSドメイン名]]が[[伝統的ドメイン名]]なら、
[[ASCII大文字・小文字不区別]]で各[[ラベル]]を順に比較しなければ[['''なりません''']]。
[[参照識別子]]の[[DNSドメイン名]]が [[IDN]] なら、
[[Uラベル]]を[[Aラベル]]に変換した上で、
[[ASCII大文字・小文字不区別]]で各[[ラベル]]を順に比較しなければ[['''なりません''']]。
[SRC[>>33]]

[58] [[ワイルドカード文字]]の扱いについては、[[ワイルドカード証明書]]の項を参照。

** 応用サービス型の比較

[59] [[SRV-ID]] や [[URI-ID]] については[[応用サービス型]]の[[一致]]も検査しなければ[['''なりません''']] [SRC[>>33]]。

[60] [[SRV-ID]] の応用サービス名部分は、 [[DNS]] [CODE[[[SRV]]]] の仕様にそって[[大文字・小文字不区別]]で比較しなければ[['''なりません''']] [SRC[>>33]]。

[61] [[URI-ID]] の [[URL scheme]] 部分は、 [[URL]] の仕様にそって[[大文字・小文字不区別]]で比較しなければ[['''なりません''']] [SRC[>>33]]。

** 一致判定

[62] [[証明書]]に示された識別子で[[資源識別子]]に[[一致]]するものが見つかれば、
[[service identity]] の検査は成功です。[[クライアント]]はその[[資源識別子]]を当該[[応用サービス]]の[RUBYB[検証済み]@en[validated]] [[identity]]
として使わなければ[['''なりません''']] [SRC[>>33]]。

[63] [[証明書]]に示された識別子で[[資源識別子]]に[[一致]]するものが見つからなかった場合で、
以前に当該[[応用サービス]]の[[証明書]]をいずれかの[[資源識別子]]に [[pin]]
している場合で、[[証明書]]が [[pin]] された[[証明書]]と一致する場合には、
[[service identity]] の検査は成功です [SRC[>>33]]。

[64] [[証明書]]に示された識別子で[[資源識別子]]に[[一致]]するものが見つからなかった場合で、
[[pin]] された[[証明書]]もない場合、[[対話的]]なクライアントは[[利用者]]に
[[identity]] が一致しなかったと通知し、通信は問題ある[[証明書]]であるとの[[誤り]]により自動的に終端する[['''べきです''']] [SRC[>>33]]。

[65] [[対話的]]なクライアントの中には、その場合であっても処理を続行する、
つまり[[証明書]]を [[pin]] する選択肢を[[利用者]]に示すものもあります。
特殊な状況ではそのような動作も必要かもしれませんが、高度な利用者のみに提示するべきものです。
しかも極めて注意して取り扱うべきものですから、 [[pin]] する前に [[certification path]]
全体の確認を強制するなど注意が必要です。 [SRC[>>33]]

[66] クライアントが[[人間]]利用者が直接制御しない自動化された応用である場合には、
問題ある[[証明書]]であるとの[[誤り]]により自動的に終端し、誤りを適宜記録する[['''べきです''']]。
これを抑制する設定を設けても構いませんが、既定値としては[['''なりません''']]。 [SRC[>>33]]

;; [68] [[pin]] は、示された[[証明書]]とその承認された文脈の両方を考慮しなければ[['''なりません''']]。
ここでいう文脈とは、当該[[証明書]]から trust anchor までの[[証明書鎖]]、
[[source domain]]、[[応用サービス型]]、サービスの [[derived domain]]
や[[ポート番号]]、その他[[利用者]]や[[クライアント]]が持つ関係する情報を含みます。 [SRC[>>33]]

* HTTPS サーバー認証

[154] [[クライアント]]は、[[鯖]]の[[ホスト名]]が分かっているなら、
[[鯖]]の [CODE[[[Certificate]]]] [[メッセージ]]に示された[[鯖]]の [[identity]]
を検査しなければ[['''なりません''']]。
通常は [[URL]] で指定された[[ホスト]]に[[要求]]を送信するので、
[[ホスト名]]は既知です。 [SRC[>>151]]

[156] 型 [[dNSName]] の [[subjectAltName]]  拡張が示されている場合には、
これを [[identity]] として使わなければなりません。そうでない場合には、
[[証明書]]の [[Subject]] 欄の (最も詳細な) [[Common Name]] 欄を [[identity]]
として使わなければ[['''なりません''']]。 [SRC[>>151]]

;; [157] [[Common Name]] を使うのが慣習となっていますが、[[非推奨]]であり、 [[dNSName]]
が推奨されています [SRC[>>151]]。

;; [122] 「最も詳細な」の部分について、 [[RFC 6125]] は混乱があることを指摘し、
[CODE[[[CN]]]] が複数含まれない場合のみ [[CN-ID]] とみなすことにしています
([[RDN]]、[[CN-ID]] 参照)。ただし [[RFC 6125]] は [[RFC 2818]] を更新するものではなく、
また [[HTTPS]] の実装が実際にどう処理するかは定かではありません。

[158] [[一致]]の判定は、 [[RFC 2459]] の規則によります。
複数の [[identity]] が示されている場合には、いずれかに[[一致]]すれば[[一致]]とします。
[SRC[>>151, >>168]] [[ワイルドカード文字]]も使えます。

;; [[ワイルドカード証明書]]も参照。

[161] [[ホスト名]]ではなく [[IPアドレス]]を指定して接続する場合には、
[[証明書]]の [CODE[[[subjectAltName]]]] 拡張の [CODE[[[iPAddress]]]] と完全に[[一致]]しなければなりません。
[SRC[>>151]]

;; [125] 実際の [[Webブラウザー]]は [CODE[[[CN]]]] が [[IPアドレス]]と完全に[[一致]]することでも構わないとしているようです [SRC[>>124]]。
[REFS[
- [124] [CITE[IO::Socket::SSL - search.cpan.org]] ([TIME[2015-03-31 23:57:50 +09:00]] 版) <http://search.cpan.org/dist/IO-Socket-SSL/lib/IO/Socket/SSL.pod#verify_hostname($hostname,$scheme,$publicsuffix)>
]REFS]

;; [180] [[IPP]] over [[HTTPS]] は [[IPアドレス]]が指定された場合に[[証明書]]の検証が難しいとして、
[CODE(URI)@en[[[ipps:]]]] [[URL]] に[[IPアドレス]]を指定する[['''べきではない''']]
[SRC[>>179]] としています。
[REFS[
- [179] [CITE@en[RFC 7472 - Internet Printing Protocol (IPP) over HTTPS Transport Binding and the 'ipps' URI Scheme]] ([TIME[2015-03-04 12:23:14 +09:00]] 版) <https://tools.ietf.org/html/rfc7472#section-4.2>
]REFS]

[172] [[クライアント]]は信頼する [[CA]] を注意深く選び、
信頼する [[CA証明書]]を保存する場所が不正に改変されないよう注意するべきです [SRC[>>171]]。

;; [170] これらの [[identity]] の検査のことを、
[DFN[[RUBYB[HTTPSサーバー認証]@en[HTTPS server authentication]]]] [SRC[>>171]]
などと呼ぶことがあります。
[REFS[
- [171] [CITE@en[RFC 6819 - OAuth 2.0 Threat Model and Security Considerations]] ([TIME[2015-02-10 06:43:00 +09:00]] 版) <http://tools.ietf.org/html/rfc6819#section-5.1.2>
]REFS]

[155] [[クライアント]]が外部情報により[[鯖]]の期待される [[identity]]
を承知しているなら、[[ホスト名]]の検査を省略できます。
例えば[[番地]]と[[ホスト名]]が動的に決まる[[機械]]に接続する場合で、
[[鯖]]が示す[[証明書]]が分かっているなら、省略できます。
特別な場合には[[鯖]]の [[identity]] を完全に無視しても構いませんが、
危険なことは理解しなければなりません。 [SRC[>>151]]

[162] [[ホスト名]]と[[証明書]]の [[identity]] が[[一致]]しない場合には、
[[利用者]]指向の[[クライアント]]は[[利用者]]にこれを通知するか、
[[証明書]]誤りにより[[接続]]を終端するかのいずれかとしなければ[['''なりません''']]。
通知する場合には、[[利用者]]に[[接続]]を継続するか選択させても構いません。
自動化された[[クライアント]]は (あれば) [[誤り]]を記録しなければ[['''ならず''']]、
[[証明書]]誤りにより[[接続]]を終端する[['''べきです''']]。
自動化された[[クライアント]]は設定によりこの検査を無効化しても構いませんが、
有効にする設定を設けなければ[['''なりません''']]。 [SRC[>>151]]

;; [163] なお、 [[URL]] など[[接続]]先の[[ホスト名]]が外部の信頼できない情報源からもたらされた場合、
[[identity]] を検査したとしても攻撃を回避できるわけではありません。
[[利用者]]は[[鯖]]の[[証明書]]を注意して調べるなどの対策が必要です。 [SRC[>>151]]
一般的な [[Webブラウザー]]は[[証明書]]の一部の情報を[[アドレスバー]]などに表示すると共に、
詳細な情報を表示する方法を提供しています。

[106] [[対話的]]な [[Webブラウザー]]は、原則としてこれらの規定に従うものの、
[[利用者]]の判断により名前が一致しない[[証明書]]であっても個別に閲覧を認められるのが一般的です。
[[Webアプリケーション]]の開発用[[鯖]]など一般向けでない場合を中心に、
そのような利用方法が可能なことに依存している場合もあります。
非[[対話的]]な[[利用者エージェント]]も、[[証明書]]の検証を省略する動作モードを用意していることが普通です。

;; [107] [[ルート証明書]]の更新などの[[クライアント]]側で必要な作業がそのような[[利用者エージェント]] (の動作環境) では蔑ろにされがちであり、
そのような環境でも [[HTTPS]] [[鯖]]に意図通り接続させるため、敢えて検証を省略する状態で[[シェルスクリプト]]等が記述されていることも少なくありません。
(もちろん、これは好ましい状況ではありません。ただ[[証明書]]にまつわるトラブルは珍しくなく、
原因の究明と対策は一般の開発者にとって難しいため、
このような回避策を取らざるをえない場合があることも残念ながら事実です。)

* 実装

[77] 複数の[[プロトコル]]での利用を想定した実装では、プロトコル名などを指定して[[ワイルドカード]]の動作を切り替えられることがあります。

[REFS[
- [78] [CITE[IO::Socket::SSL - search.cpan.org]] ([TIME[2015-03-31 23:57:50 +09:00]] 版) <http://search.cpan.org/dist/IO-Socket-SSL/lib/IO/Socket/SSL.pod#verify_hostname($hostname,$scheme,$publicsuffix)>
- [79] [CITE[AnyEvent::TLS - search.cpan.org]] ([TIME[2015-03-31 23:58:46 +09:00]] 版) <http://search.cpan.org/dist/AnyEvent/lib/AnyEvent/TLS.pm#verify_peername_=>_$scheme_|_$callback->($tls,_$cert,_$peername)>
]REFS]


[84] [CITE@en[552346 – Stop honoring DNS names found in subject common names in CERT_VerifyCertName]]
([TIME[2015-04-02 12:16:38 +09:00]] 版)
<https://bugzilla.mozilla.org/show_bug.cgi?id=552346>

[85] [CITE@ja-JP[高木浩光@自宅の日記 - こんな銀行は嫌だ, オレオレ証明書の区分 第三版]]
([[高木浩光]] 著, [TIME[2010-07-09 22:26:18 +09:00]] 版)
<http://takagi-hiromitsu.jp/diary/20071117.html>

[FIG(quote)[
[FIGCAPTION[
[86] [CITE[Netscape Certificate Extensions Specification]]
([TIME[2015-04-06 14:43:03 +09:00]] 版)
<http://web.archive.org/web/19970727173508/http://home.netscape.com/eng/security/cert-exts.html>
]FIGCAPTION]

> netscape-ssl-server-name:'''['''Not supported until 3.0b5''']'''
> The value is an IA5String. It is a "shell expression" that can be used to match the hostname of the SSL server that is using this certificate. It is recommended that if the server's hostname does not match this pattern the user be notified and given the option to terminate the SSL connection. If this extension is not present then the CommonName in the certificate subject's distinguished name is used for the same purpose.

]FIG]


[87] [CITE@en[1184059 – (presumably) mozilla::pkix disallows several hyphens in domain label]]
([TIME[2015-07-16 10:56:21 +09:00]] 版)
<https://bugzilla.mozilla.org/show_bug.cgi?id=1184059>

[88] [CITE@en[660749 – (CVE-2011-0082) Firefox doesn't (re)validate certificates when loading a HTTPS page from the cache]]
([TIME[2015-08-28 18:26:06 +09:00]] 版)
<https://bugzilla.mozilla.org/show_bug.cgi?id=660749>

[89] [CITE[Phishing for Confirmations --- Certificate spoofing with subjectAltName and domain name wildcards]]
([TIME[2007-11-27 21:41:47 +09:00]] 版)
<http://nils.toedtmann.net/pub/subjectAltName.txt>

[FIG(quote)[
[FIGCAPTION[
[90] [CITE@en[RFC 7592 - OAuth 2.0 Dynamic Client Registration Management Protocol]]
([TIME[2015-07-15 00:25:47 +09:00]] 版)
<https://tools.ietf.org/html/rfc7592>
]FIGCAPTION]

> When using TLS, the client MUST perform a TLS/SSL
>    server certificate check, per RFC 6125 '''['''RFC6125''']'''. 

]FIG]


[FIG(quote)[
[FIGCAPTION[
[91] [CITE@en[RFC 7591 - OAuth 2.0 Dynamic Client Registration Protocol]]
([TIME[2015-07-15 00:25:14 +09:00]] 版)
<https://tools.ietf.org/html/rfc7591>
]FIGCAPTION]

> When using TLS, the client MUST perform a
>    TLS/SSL server certificate check, per RFC 6125 '''['''RFC6125''']'''.

]FIG]


[92] [CITE@en[RFC 7817 - Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols]]
([TIME[2016-03-31 07:46:22 +09:00]] 版)
<https://tools.ietf.org/html/rfc7817>