[82]

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

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

仕様書

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

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

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

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

[5] アプリケーションプロトコルの設計では、次の点を考慮するべきです >>4。

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

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

>>4

です。

[131] IETF 的には、個々のアプリケーションプロトコルがそれぞれにおける service identity の検証方法を定めるべきである、ということになっています。共通 RFC 出版以前に策定されたプロトコルも、明示的に仕様書が改定されない限りは、従前の規定が有効とされています。

[132] しかし、 SRV-ID や URI-ID やその他アプリケーション依存の識別子型に関するものはともかく、最も広く用いられているホストに関する検証で、アプリケーションごとに証明書に記述するべき内容が異なるとすると、証明書の利用者はアプリケーションごとに異なる証明書を入手し設定する必要がありますし、証明書を利用する TLS の実装はプロトコル共通の検証の実装を持つことができず、アプリケーション非依存の通信当事者認証の仕組みであるはずの PKIX の旨味も半減です。

[133] 実際問題、ホストの認証に関するプロトコルや仕様書間で規定が異なる部分は厳密に仕様書通りに実装されているとは限らず、実装ごとに解釈が異なる危険な領域であると認識するべきでしょう。

検証

[34] アプリケーションプロトコルのクライアントは、 service identity を次のようにして検証verifyします >>33。

[35] 利用者の入力等に基づき、受け入れる参照識別子のリストを作成します。
[36] サーバー証明書からサーバーの識別子を得ます。
[37] 参照識別子とサーバーの識別子が一致するか検査します。

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

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

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

[71]

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

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

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

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

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

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

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

>>33

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

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

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

>>33

。

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

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

[48] Webブラウザーは、 www.example.com の HTTPS において

DNS-ID www.example.com
フォールバック CN-ID www.example.com

... を含めることができます

>>33

。

[49] MUA は、 IMAPS example.net が mail.example.net に解決される時、

SRV-ID _imaps.example.net
DNS-ID example.net
DNS-ID mail.example.net
フォールバック CN-ID example.net
フォールバック CN-ID mail.example.net

... を含めることができます

>>33

。

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

>>33

ドメイン名の比較

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

[99] Chrome も Firefox も、証明書のドメイン名が大文字でも、一致すると判定します。 2016-05-08T09:39:49.900Z

[100] Chrome も Firefox も、証明書のドメイン名が非ASCII文字を含む時、一致しないとみなします。 2016-05-08T09:42:49.500Z

[101] ただし Chrome は、証明書のドメイン名が非ASCII文字を含んでも、それを正規化すると URL の Aラベルとなるなら、一致するとみなすようです。 2016-05-08T09:45:41.000Z

[103] Chrome でも Firefox でも、証明書のドメイン名が PSL に含まれるものであっても、かわらず普通に扱います。 2016-05-08T12:12:40.600Z

[104] Chrome でも Firefox でも、証明書のドメイン名が内部名であっても、かわらず普通に扱います。 2016-05-08T12:13:35.800Z

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

[95] 末尾の点も参照。

応用サービス型の比較

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

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

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

一致判定

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

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

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

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

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

[68]

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

>>33

HTTPS サーバー認証

[134] HTTPSサーバー認証は、 RFC 2818 により定められています。

[135] RFC 6125 に基づく改訂は、未だ行われていません。

[136] JWSの取得プロトコルは RFC 6125 による認証を求めています。

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

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

[157]

Common Name を使うのが慣習となっていますが、非推奨であり、 dNSName が推奨されています

>>151

。

[97] Chrome も Firefox も、 SAN があるとき、 CN を無視します。 (仕様通りの動作。) 2016-05-08T09:16:53.100Z

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

[98] Chrome は、 CN が複数ある時、最後のものを採用するようです。 Firefox は、最初のものを採用するようです。 2016-05-08T09:26:37.00Z

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

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

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

[125] 実際の Webブラウザーは、 SAN がないとき、 CN が IPアドレスと完全に一致するなら、一致とみなします >>124。 Chrome も Firefox も CN に IPv4アドレスを指定すると、そのように動作します。 2016-05-08T08:24:55.500Z

[110] Chrome でも Firefox でも、これは正規形の IPv4アドレスの文字列表現でなければ認識されません。 2016-05-08T13:05:48.600Z

[105] Chrome >>102 と Firefox >>118 のソースコードによると、この扱いは IPv4アドレスのみで、 IPv6アドレスには適用されないようです。

[108] SAN がないというのは、 DNS-ID と IPアドレスの指定がどちらもないことをいいます。他の、例えばメールアドレスの指定があっても、 Firefox も Chrome も、 CN-ID を使います。 2016-05-08T12:39:37.100Z

[124] IO::Socket::SSL - search.cpan.org (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)

[96] Chrome も Firefox も、 CN と SAN にIPv4アドレスを指定しても、 IPアドレスの URL でアクセスした時一致とみなしませんでした。 2016-05-08T08:10:46.00Z

[93] Chrome も Firefox も、IPアドレスの記述のない証明書のとき、 IPアドレスの URL でのアクセスでエラーとします。 2016-05-08T04:58:29.00Z

[180]

IPP over HTTPS は IPアドレスが指定された場合に証明書の検証が難しいとして、 ipps: URL にIPアドレスを指定するべきではない

>>179

としています。

[179] RFC 7472 - Internet Printing Protocol (IPP) over HTTPS Transport Binding and the 'ipps' URI Scheme (2015-03-04 12:23:14 +09:00 版) https://tools.ietf.org/html/rfc7472#section-4.2

[129] Chrome も Firefox も、2017年には CN への対応を原則として廃止しました。

[126] 308330 - Remove support for common names in certificates; only support Subject Alt Names - chromium - Monorail ( (2017-05-22 19:11:36 +09:00)) https://bugs.chromium.org/p/chromium/issues/detail?id=308330
[127] 1245280 - don't fall back to subject common name for name information for new certificates ( (2017-05-22 19:12:27 +09:00)) https://bugzilla.mozilla.org/show_bug.cgi?id=1245280
[128] 700595 - Chrome no longer accepts certificates that fallback to common name (ERR_CERT_COMMON_NAME_INVALID) - chromium - Monorail ( (2017-05-22 19:15:26 +09:00)) https://bugs.chromium.org/p/chromium/issues/detail?id=700595&desc=2

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

[170] これらの identity の検査のことを、 HTTPSサーバー認証HTTPS server authentication

>>171

などと呼ぶことがあります。

[171] RFC 6819 - OAuth 2.0 Threat Model and Security Considerations (2015-02-10 06:43:00 +09:00 版) http://tools.ietf.org/html/rfc6819#section-5.1.2

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

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

[163] なお、 URL など接続先のホスト名が外部の信頼できない情報源からもたらされた場合、 identity を検査したとしても攻撃を回避できるわけではありません。利用者は鯖の証明書を注意して調べるなどの対策が必要です。

>>151

一般的な Webブラウザーは証明書の一部の情報をアドレスバーなどに表示すると共に、詳細な情報を表示する方法を提供しています。

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

[107]

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

[137] 検証エラーがリダイレクトに置き換えられるケースがあります。 HTTPS

実装

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

[78] IO::Socket::SSL - search.cpan.org (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] AnyEvent::TLS - search.cpan.org (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)>

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

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

[86]

Netscape Certificate Extensions Specification (2015-04-06 14:43:03 +09:00 版) http://web.archive.org/web/19970727173508/http://home.netscape.com/eng/security/cert-exts.html

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.

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

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

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

[90]

RFC 7592 - OAuth 2.0 Dynamic Client Registration Management Protocol (2015-07-15 00:25:47 +09:00 版) https://tools.ietf.org/html/rfc7592

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

[91]

RFC 7591 - OAuth 2.0 Dynamic Client Registration Protocol (2015-07-15 00:25:14 +09:00 版) https://tools.ietf.org/html/rfc7591

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

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

[94] OpenSSL ( (OpenSSL Foundation, Inc.著, 2016-05-08 14:12:01 +09:00)) https://www.openssl.org/docs/manmaster/crypto/X509_check_host.html

[102] [chrome] Contents of /trunk/src/net/cert/x509_certificate.cc ( (2016-05-08 20:07:31 +09:00)) https://src.chromium.org/viewvc/chrome/trunk/src/net/cert/x509_certificate.cc#l504

[109] 469533 – FireFox 3.0.6 only processes 'Last' CN in x509 certificate when multiple CNs are present - ssl_error_bad_cert_domain ( (2016-05-08 22:03:35 +09:00)) https://bugzilla.mozilla.org/show_bug.cgi?id=469533

[111] 1063281 – Implement RFC6125-compliant name matching in mozilla::pkix ( (2016-05-08 22:09:05 +09:00)) https://bugzilla.mozilla.org/show_bug.cgi?id=1063281

[112] 1089104 – ssl_error_bad_cert_domain when subjectAltName extension is missing and Subject CN is encoded as TeletexString ( (2016-05-08 22:40:14 +09:00)) https://bugzilla.mozilla.org/show_bug.cgi?id=1089104

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

[114] 1245280 – don't fall back to subject common name for name information for new certificates ( (2016-05-08 22:45:11 +09:00)) https://bugzilla.mozilla.org/show_bug.cgi?id=1245280

[115] gecko-dev/BRNameMatchingPolicy.cpp at master · mozilla/gecko-dev ( (2016-05-10 23:07:42 +09:00)) https://github.com/mozilla/gecko-dev/blob/master/security/certverifier/BRNameMatchingPolicy.cpp

[116] gecko-dev/BRNameMatchingPolicy.h at master · mozilla/gecko-dev ( (2016-05-10 23:07:59 +09:00)) https://github.com/mozilla/gecko-dev/blob/master/security/certverifier/BRNameMatchingPolicy.h

[117]

gecko-dev/CertVerifier.cpp at master · mozilla/gecko-dev ( (2016-05-10 23:08:23 +09:00)) https://github.com/mozilla/gecko-dev/blob/master/security/certverifier/CertVerifier.cpp

BRNameMatchingPolicy nameMatchingPolicy(
isBuiltInRoot ? mNameMatchingMode
: BRNameMatchingPolicy::Mode::DoNotEnforce);

[118] gecko-dev/pkixnames.cpp at master · mozilla/gecko-dev ( (2016-05-10 23:12:11 +09:00)) https://github.com/mozilla/gecko-dev/blob/master/security/pkix/lib/pkixnames.cpp

[119]

不正なSSL証明書のチェックをしないモバイルアプリにご注意を | スラドセキュリティ ( (2016-07-20 16:27:54 +09:00)) http://security.srad.jp/story/14/02/14/0943234/

テキサス大学オースティン校およびスタンフォード大学の研究者らによる研究(PDF)によると、Amazon EC2のJavaライブラリやAmazonおよびPayPalのSDK、ECサイト構築ソフトウェア、モバイル向けの広告コードなどで、証明書が正しく検証されていない例が確認されたという。また、iOS向けのネットバンキングアプリの40%で、証明書の検証に不備があるとも述べられている(Netcraft)。

[120] 1250696 – .onion names contain their own validator, we should use that (2016-09-01 15:43:11 +09:00) https://bugzilla.mozilla.org/show_bug.cgi?id=1250696

[138] Ballot 144 - Validation rules for .onion names - CAB Forum, 2021-02-06T03:56:24.000Z https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/

[121] 「国税クレジットカードお支払サイト」は誰が運営するサイトなのか - Togetterまとめ (2017-01-06 16:26:48 +09:00) https://togetter.com/li/1067266

[123] RFC 8143 - Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP) (2017-04-23 23:13:44 +09:00) https://tools.ietf.org/html/rfc8143

[130] Define hosts' public suffix and registrable domain. by mikewest · Pull Request #391 · whatwg/url (2018-06-13 22:16:00 +09:00) https://github.com/whatwg/url/pull/391

仕様書

ドメイン名

IP アドレス

証明書

CSR

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

検証

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

ドメイン名の比較

応用サービス型の比較

一致判定

HTTPS サーバー認証

実装