Contents
- 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)
https://datatracker.ietf.org/doc/html/rfc6125
7.2. Wildcard Certificates
1. history
o Wildcard certificates automatically vouch for any and all host
names within their domain. This can be convenient for
administrators but also poses the risk of vouching for rogue or
buggy hosts. See for example [Defeating-SSL] (beginning at slide
91) and [HTTPSbytes] (slides 38-40). o Specifications for existing application technologies are not clear
or consistent about the allowable location of the wildcard
character, such as whether it can be:
* only the complete left-most label (e.g., *.example.com)
* some fragment of the left-most label (e.g., fo*.example.com,
f*o.example.com, or *oo.example.com)
* all or part of a label other than the left-most label (e.g.,
www.*.example.com or www.foo*.example.com)
* all or part of a label that identifies a so-called "public
suffix" (e.g., *.co.uk or *.com)
* included more than once in a given label (e.g.,
f*b*r.example.com
* included as all or part of more than one label (e.g.,
*.*.example.com)
These ambiguities might introduce exploitable differences in
identity checking behavior among client implementations and
necessitate overly complex and inefficient identity checking
algorithms. o There is no specification that defines how the wildcard character
may be embedded within the A-labels or U-labels [IDNA-DEFS] of an
internationalized domain name [IDNA-PROTO]; as a result,
implementations are strongly discouraged from including or
attempting to check for the wildcard character embedded within the
A-labels or U-labels of an internationalized domain name (e.g.,
"xn--kcry6tjko*.example.org"). Note, however, that a presented
domain name identifier MAY contain the wildcard character as long
as that character occupies the entire left-most label position,
where all of the remaining labels are valid NR-LDH labels,
A-labels, or U-labels (e.g., "*.xn--kcry6tjko.example.org").
Notwithstanding the foregoing security considerations, specifications
that reuse this one can legitimately encourage continued support for
the wildcard character if they have good reasons to do so, such as
backward compatibility with deployed infrastructure (see, for
example, [EV-CERTS]).