wildcard certificate

ワイルドカード証明書 (PKI)

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

仕様書

旧来の仕様

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

HTTPS

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

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

[160] 例えば f*.comfoo.com に一致します。 >>151

[169] ですが、一般には *最左ラベルとして1つだけ用いられます >>168
[167] ワイルドカードの処理は RFC 2459 になく、 RFC 2818 側で規定されています。後に RFC 3280RFC 5280 と改訂されていますが、 この点は変わっていないようです。

[49] Chrome でも Firefox も、ワイルドカードを使えるのは最左ラベル1つだけのようです。

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

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

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

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

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

RFC 6125

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

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

ワイルドカードの使用

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

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

[16] ワイルドカード文字の使い方には次のようなバリエーションがあり、 仕様や実装により扱いの違いが生じていることがあります >>14

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

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

比較

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

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

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

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

[9] *.example.comfoo.example.com と一致しますが、 bar.foo.example.comexample.com とは一致しません >>4

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

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

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

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

CA/Browser Forum

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

[40] ( 版) <https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf#page=12>

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.

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

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

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

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

歴史

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

[1] 159483 – cert name matching: RFC 2818 vs. backwards compatibility (wildcards) ( 版) <https://bugzilla.mozilla.org/show_bug.cgi?id=159483>

[2] IETF - TLS - RFC 2818 wildcard rationale ( 版) <http://ietf.10.n7.nabble.com/RFC-2818-wildcard-rationale-td246010.html>

[3] 903885 – (CVE-2014-1492) Hostname matching code violates RFC 6125 for IDNA ( 版) <https://bugzilla.mozilla.org/show_bug.cgi?id=903885>

実装

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

関連

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

メモ

[52] 578697 – (CVE-2010-3170) Browser Wildcard Certificate Validation Issue ( ()) <https://bugzilla.mozilla.org/show_bug.cgi?id=578697>

[54] 921127 – In PSM don't provide EV treatment when cert includes wildcards in the alt-dns name and common name fields ( ()) <https://bugzilla.mozilla.org/show_bug.cgi?id=921127>

[56] 285361 – acceptance of wildcard certs makes MITM attacks easier for rogue proxy ( ()) <https://bugzilla.mozilla.org/show_bug.cgi?id=285361>

[57] 806281 – Certificate validation does not properly prohibit *.<tld> wildcard certificates ( ()) <https://bugzilla.mozilla.org/show_bug.cgi?id=806281>

[58] Issue 100442 - chromium - Should wildcards in certificates be allowed to match registry controlled TLDs - Monorail ( ()) <https://bugs.chromium.org/p/chromium/issues/detail?id=100442>

[59] 1136616 – mozilla::pkix name matching disallows some characters in reference IDs that are valid in DNS labels ( ()) <https://bugzilla.mozilla.org/show_bug.cgi?id=1136616>

[60] 1196364 – Proper handling for wildcard certificates for all tlds ( ()) <https://bugzilla.mozilla.org/show_bug.cgi?id=1196364>

[62] Wildcard Certificates Coming January 2018 - Let's Encrypt - Free SSL/TLS Certificates () <https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html>

[63] Wildcard Certificates Coming January 2018 - Let's Encrypt - Free SSL/TLS Certificates () <https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html>

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.

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