Edit

Page

Page title:

Page body:

[36] [DFN[[RUBYB[ワイルドカード証明書]@en[wildcard certificate]]]]は、
[[ドメイン名]]に[[ワイルドカード文字]] [DFN[[CODE[[[*]]]]]] を使った[[証明書]]です。
[[ワイルドカード文字]]は、任意の[[ドメイン名]][[ラベル]]との[[一致]]を表しています。

* 仕様書

[REFS[
- [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-6.4.3>
- [14] [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.2>
- [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#appendix-B>
- [28] [CITE[RFC Errata Report]] ([TIME[2015-03-31 23:46:08 +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>
- [42] [[BR]] ([TIME[2014-11-01 05:54:38 +09:00]] 版)
<https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf#page=12>
- [41] [CITE[[[BR]]]] ([TIME[2014-11-01 05:54:38 +09:00]] 版) <https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf#page=17>
- [44] [CITE[[[BR]]]] ([TIME[2014-11-01 05:54:38 +09:00]] 版) <https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf#page=25>
]REFS]

* 旧来の仕様

[27] [[RFC 6125]] の附属書B [SRC[>>26]] には、既存の [[IETF]] の仕様における [[service identity]]
検査の規定がまとめられています。多くの仕様には[[ワイルドカード]]の規定がありますが、
その内容は少しずつ違いがあります。 [[DNS-ID]] には[[ワイルドカード]]が適用され、
[[CN-ID]] には適用されないとするものもあるようです。

* HTTPS

[34] [[ワイルドカード]] [CODE[[[*]]]] を含む名前は、
単一の[RUBYB[[[ドメイン名部品]]]@en[domain name component]]に[[一致]]するものとします。
[SRC[>>151, >>168]]

[EG[
[159] 例えば [CODE[*.a.com]] は [CODE[foo.a.com]] に一致しますが、
[CODE[bar.foo.a.com]] には一致しません。 [SRC[>>151]]
]EG]

[EG[
[160] 例えば [CODE[f*.com]] は [CODE[foo.com]] に一致します。 [SRC[>>151]]
]EG]

;; [169] ですが、一般には [CODE[[[*]]]] は[[最左ラベル]]として1つだけ用いられます
[SRC[>>168]]。

;; [167] [[ワイルドカード]]の処理は [[RFC 2459]] になく、 [[RFC 2818]]
側で規定されています。後に [[RFC 3280]]、 [[RFC 5280]] と改訂されていますが、
この点は変わっていないようです。

[49] [[Chrome]] でも [[Firefox]] も、[[ワイルドカード]]を使えるのは[[最左ラベル]]1つだけのようです。
[TIME[2016-05-08T11:00:07.500Z]]

[50] [[Chrome]] でも [[Firefox]] でも、[[ワイルドカード]]はそれ全体が[[ドメイン名部品]]でないと認識しないようです。
他の[[文字]]と混在させられません。 [TIME[2016-05-08T11:00:42.300Z]]

[51] [[Chrome]] は、 [[ワイルドカード]] + [[ラベル]]0個[[以上]] +
[[eTLD+1]] という形でないと認識しないようです。
[[eTLD]] は、 [[PSL]] にない場合、 [[TLD]] のみとみなします。
ここでいう [[eTLD]] は、 [[PSL]] のうち、正式に登録されたもの ([[ICANNドメイン]]) をいいます
([CODE[.herokuapp.com]] のようなものは含まないので、
[CODE[*.herokuapp.com]] のような[[ワイルドカード証明書]]は有効です)。
[TIME[2016-05-08T11:01:42.700Z]]

[55] [[Firefox]] は、 [[PSL]] の検査をしておらず、 [[ワイルドカード]] + [[TLD]]
は禁止していますが、[[ワイルドカード]] + 複数[[ラベル]]の [[eTLD]]
は禁止していないようです。 [TIME[2016-05-08T13:13:05.300Z]]

[53] 古い時代の [[Webブラウザー]]は、 [[CN]] に[[ワイルドカード]]混じりの[[IPv4アドレス]]を指定することができてしまいました。
これは[[脆弱性]]であり、現行 [[Webブラウザー]]では認められていません。

;; [35] [[ワイルドカード]]以外の処理は、[[service identity]] を参照。

* RFC 6125

[12] [[RFC 6125]] は [[TLS]] において[[証明書]]を使って [[service identity]]
を検証する方法を規定しており、その中で[[ワイルドカード文字]]を含む[[ドメイン名]]の解釈についても規定しています。
この規定は、 [[RFC 6125]] を採用する仕様にのみ適用されます。

;; [[service identity]] も参照。

;; [13] [[HTTPS]] 仕様は現在事実上メンテナンスされていない状態にあり、
[[RFC 6125]] を採用するとは明記されていないものの、
[[RFC 6125]] に反する挙動がセキュリティーホールとみなされた例 (>>3) もあります。

** ワイルドカードの使用

[15] [[証明書]]で[[ワイルドカード文字]]は使用する[['''べきではありません''']]。
[[ワイルドカード証明書]]はドメイン内のすべてのホストを自動的に認めてしまうものなので、
管理者にとっては便利かもしれませんが、危険も伴うものです。また、
既存の[[アプリケーション]]は[[ワイルドカード文字]]を認める位置が不明瞭であったり、
差異があったりします。[[Aラベル]]や [[Uラベル]]での[[ワイルドカード文字]]の扱いを定義した仕様もありませんでした。 [SRC[>>14]]

;; [25] しかし[[後方互換性]]その他の理由で[[ワイルドカード]]が必要な仕様は、
[[ワイルドカード]]の使用を続けても構いません。 [SRC[>>14]]

[16] [[ワイルドカード文字]]の使い方には次のようなバリエーションがあり、
仕様や実装により扱いの違いが生じていることがあります [SRC[>>14]]。
[FIG(list)[
- [17] 最左ラベル全体 ([CODE[*.example.com]])
- [18] 最左ラベルの一部 ([CODE[fo*.example.com]])
- [19] 最左でないラベルの一部または全部 ([CODE[www.*.example.com]])
- [20] [[public suffix]] の一部または全部を表すもの ([CODE[*.co.uk]])
- [21] ラベル中に複数含まれる ([CODE[f*b*r.example.com]])
- [22] 複数のラベルに含まれる ([CODE[*.*.example.com]])
]FIG]

[23] 実装が[[Uラベル]]や[[Aラベル]]に[[ワイルドカード文字]]を含めたり、
検査したりすることは[RUBYB[強く非推奨]@en[strongly discouraged]]です。
ただし[[最左ラベル]]が[[ワイルドカード文字]]でそれ以外が
[[NR-LDHラベル]]、[[Aラベル]]、[[Uラベル]]であるのは構いません。 [SRC[>>14]]

[EG[
[24] 例えば [CODE[xn--kcry6tjko*.example.org]] は問題ありますが、
[CODE[*.xn--kcry6tjko.example.org]] は問題ありません。 [SRC[>>14]]
]EG]

** 比較

[5] [[クライアント]]は、[[ラベル]]の一部または全部が[[ワイルドカード文字]]
[CODE[[[*]]]] である[[DNSドメイン名]]が識別子として[[証明書]]に示されている時に、
[[参照識別子]]と[[一致]]するか次の通り検査することができます [SRC[>>4]]。

[6] [RUBYB[最左ラベル]@en[left-most label]]以外に[[ワイルドカード文字]]が含まれる識別子が[[証明書]]に示されていても、
一致するか調べる[['''べきではありません''']] [SRC[>>4]]。

[EG[
[7] [CODE[bar.*.example.net]] との一致を調べるべきではありません [SRC[>>4]]。
]EG]

[8] [[証明書]]に示されている識別子の最左ラベル全体が[[ワイルドカード文字]]の時は、
[[参照識別子]]の最左ラベル以外と比較する[['''べきではありません''']] [SRC[>>4]]。

[EG[
[9] [CODE[*.example.com]] は [CODE[foo.example.com]] と一致しますが、
[CODE[bar.foo.example.com]] や [CODE[example.com]] とは一致しません [SRC[>>4]]。
]EG]

[10] [[証明書]]に示されている識別子の[[ワイルドカード文字]]が含まれる[[ラベル]]にその他の文字が含まれる場合に、
一致するか調べても構いません。 [SRC[>>4]]

[11] [[証明書]]に示されている識別子の[[Uラベル]]や[[Aラベル]]に[[ワイルドカード文字]]が含まれている時は、
一致するか調べる[['''べきではありません''']] [SRC[>>4]]。

[29] [[public suffix]] の一部または全部を表すような[[ワイルドカード文字]]の使用 (>>20)
は禁止するべきであるはず [SRC[>>28]] ですが、 [[RFC 6125]] からそのような規定は欠落しています。

;; [30] [[IETF]] は問題があると認識しているようです [SRC[>>28]] が、
具体的な改訂作業は行われていないようです。

;; [39] [[Public Suffix List]] を使って[[証明書]]の[[ワイルドカード]]を認めるか検査する
[[Webブラウザー]]もあります [SRC[>>38]]。
[REFS[
- [38] [CITE@en[Public Suffix List/Uses - MozillaWiki]] ([TIME[2015-03-31 19:42:04 +09:00]] 版) <https://wiki.mozilla.org/Public_Suffix_List/Uses#Certificates>
]REFS]

* CA/Browser Forum

[43] [[BR]] は[DFN[[RUBYB[[[ワイルドカード証明書]]]@en[Wildcard Certificate]]]]を次のように定義しており [SRC[>>42]]、
また[DFN[[RUBYB[[[ワイルドカードFQDN]]]@en[wildcard FQDN]]]] [SRC[>>41]] という語も使っています。

[FIG(quote)[
[FIGCAPTION[
[40] ([TIME[2014-11-01 05:54:38 +09:00]] 版)
<https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf#page=12>
]FIGCAPTION]

> Wildcard Certificate: A Certificate containing an asterisk (*) in the left-most position of any of the Subject Fully-Qualified Domain Names contained in the Certificate. 
]FIG]

[45] [[BR]] に従う [[CA]] は (完全に明確とは言えませんが) [[最左ラベル]]全体としてのみ
[CODE[*]] を使う以外の[[ワイルドカード]]の使用を認められていないようです。

[46] [[BR]] に従う [[CA]] は [CODE[*]] + [[public suffix]] の[[ドメイン名]]を持つ[[証明書]]を[[発行]]しては[['''なりません''']]。
2013年9月1日より前にこの制約に反する[[証明書]]を[[失効]] ([[revoke]]) させなければ[['''なりません''']]。 [SRC[>>44]]

[47] この判定の方法は標準化されていないとしつつも、 [[PSL]] に従うのが
「best practice」である [SRC[>>44]] とされています。 [[PSL]] を使う場合は
ICANN DOMAINS のみ採用し、 PRIVATE DOMAINS は使わない[['''べき''']]です [SRC[>>44]]。

[48] [[EV証明書]]における[[ワイルドカード文字]]の使用は禁止されています。

* 歴史

@@
[61] [[ワイルドカード証明書]]が導入されたのはいつか?

[1] [CITE@en[159483 – cert name matching: RFC 2818 vs. backwards compatibility (wildcards)]]
([TIME[2015-03-16 12:47:58 +09:00]] 版)
<https://bugzilla.mozilla.org/show_bug.cgi?id=159483>

[2] [CITE[IETF - TLS - RFC 2818 wildcard rationale]]
([TIME[2015-03-16 11:57:01 +09:00]] 版)
<http://ietf.10.n7.nabble.com/RFC-2818-wildcard-rationale-td246010.html>

[3] [CITE@en[903885 – (CVE-2014-1492) Hostname matching code violates RFC 6125 for IDNA]]
([TIME[2015-03-23 23:20:36 +09:00]] 版)
<https://bugzilla.mozilla.org/show_bug.cgi?id=903885>

* 実装

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

[REFS[
- [31] [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)>
- [32] [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_=%3E_$scheme_|_$callback-%3E($tls,_$cert,_$peername)>
]REFS]

* 関連

[37] [[DNS]] における[[ワイルドカードレコード]]と直接の関係はありません。

* メモ

[52] [CITE@en[578697 – (CVE-2010-3170) Browser Wildcard Certificate Validation Issue]]
( ([TIME[2016-05-08 21:42:52 +09:00]]))
<https://bugzilla.mozilla.org/show_bug.cgi?id=578697>

[54] [CITE@en[921127 – In PSM don't provide EV treatment when cert includes wildcards in the alt-dns name and common name fields]]
( ([TIME[2016-05-08 21:49:07 +09:00]]))
<https://bugzilla.mozilla.org/show_bug.cgi?id=921127>

[56] [CITE@en[285361 – acceptance of wildcard certs makes MITM attacks easier for rogue proxy]]
( ([TIME[2016-05-08 22:51:34 +09:00]]))
<https://bugzilla.mozilla.org/show_bug.cgi?id=285361>

[57] [CITE@en[806281 – Certificate validation does not properly prohibit *.<tld> wildcard certificates]]
( ([TIME[2016-05-08 22:53:55 +09:00]]))
<https://bugzilla.mozilla.org/show_bug.cgi?id=806281>

[58] [CITE@en[Issue 100442 - chromium - Should wildcards in certificates be allowed to match registry controlled TLDs - Monorail]]
( ([TIME[2016-05-08 22:55:15 +09:00]]))
<https://bugs.chromium.org/p/chromium/issues/detail?id=100442>

[59] [CITE@en[1136616 – mozilla::pkix name matching disallows some characters in reference IDs that are valid in DNS labels]]
( ([TIME[2016-05-08 22:57:46 +09:00]]))
<https://bugzilla.mozilla.org/show_bug.cgi?id=1136616>

[60] [CITE@en[1196364 – Proper handling for wildcard certificates for all tlds]]
( ([TIME[2016-05-08 23:09:16 +09:00]]))
<https://bugzilla.mozilla.org/show_bug.cgi?id=1196364>

[62] [CITE@en[Wildcard Certificates Coming January 2018 - Let's Encrypt - Free SSL/TLS Certificates]]
([TIME[2017-07-13 02:00:04 +09:00]])
<https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html>

[FIG(quote)[
[FIGCAPTION[
[63] [CITE@en[Wildcard Certificates Coming January 2018 - Let's Encrypt - Free SSL/TLS Certificates]]
([TIME[2018-01-10 11:00:04 +09:00]])
<https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html>
]FIGCAPTION]

> Update, January 4, 2018
> We introduced a public test API endpoint for the ACME v2 protocol and wildcard support on January 4, 2018. ACME v2 and wildcard support will be fully available on February 27, 2018.

]FIG]

[64] [CITE@ja[自堕落な技術者の日記 : 最近の証明書の話題(1) 韓国政府PKIのマズいワイルドカード証明書発行 - livedoor Blog(ブログ)]]
([TIME[2018-05-20 23:17:14 +09:00]])
<http://blog.livedoor.jp/k_urushima/archives/1839344.html>

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Page name(s)