In computer networking, a wildcard certificate is a public key certificate which can be used with multiple subdomains of a domain. The principal use is for securing web sites with HTTPS, but there are also applications in many other fields. Compared with conventional certificates, a wildcard certificate can be cheaper and more convenient than a certificate for each subdomain.
Video Wildcard certificate
Example
A single wildcard certificate for https://*.example.com will secure all these subdomains on the https://*.example.com domain:
payment.example.comcontact.example.comlogin-secure.example.comwww.example.com
Instead of getting separate certificates for subdomains, you can use a single certificate for all main domains and subdomains and reduce cost.
Because the wildcard only covers one level of subdomains (the asterisk doesn't match full stops), these domains would not be valid for the certificate:
test.login.example.com
The "naked" domain is valid when added separately as a Subject Alternative Name (SubjectAltName):
example.com
Note possible exceptions by CAs, for example wildcard-plus cert by DigiCert contains an automatic "Plus" property for the naked domain example.com.
Maps Wildcard certificate
Limitations
Only a single level of subdomain matching is supported in accordance with RFC 2818.
It is not possible to get a wildcard for an Extended Validation Certificate. A workaround could be to add every virtual host name in the Subject Alternative Name (SAN) extension, the major problem being that the certificate needs to be reissued whenever a new virtual server is added. (See Transport Layer Security § Support for name-based virtual servers for more information.)
Wildcards can be added as domains in multi-domain certificates or Unified Communications Certificates (UCC). In addition, wildcards themselves can have subjectAltName extensions, including other wildcards. For example, the wildcard certificate *.wikipedia.org has *.m.wikimedia.org as a Subject Alternative Name. Thus it secures www.wikipedia.org as well as the completely different website name meta.m.wikimedia.org.
RFC 6125 argues against wildcard certificates on security grounds.
Examples
The wildcard applies only to just one label of the domain name.
label.label.label.TLD
*.domain.comis OK. It will matchwww.domain.combut notdomain.comand notzzz.www.domain.com
The wildcard may appear anywhere inside a label (aka "partial-wildcard")
f*.domain.comis OK. It will matchfrog.domain.combut notfrog.super.domain.com
baz*.example.netis OK and matchesbaz1.example.net*baz.example.netis OK and matchesfoobaz.example.netb*z.example.netis OK and matchesbuzz.example.net
Do not allow a label that consists entirely of just a wildcard unless it is the left-most label
sub1.*.domain.comis not allowed.
A cert with multiple wildcards in a name is not allowed.
*.*.domain.com
A cert with * plus a top-level domain is not allowed.
*.com
Too general and should not be allowed.
*
International domain names encoded in ASCII (A-label) are labels that are ASCII-encoded and begin with xn--.
Do not allow wildcards in an international label.
xn--caf-dma.comiscafé.comxn--caf-dma*.comis not allowedLw*.xn--caf-dma.comis allowed
References
Relevant RFCs
- "RFC 2595 - Using TLS with IMAP, POP3 and ACAP". Internet Engineering Task Force. June 1999. p. 3.
- "RFC 2818 - HTTP Over TLS". Internet Engineering Task Force. May 2000. p. 5.
- "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)". Internet Engineering Task Force. March 2011.
Source of article : Wikipedia
0 Comments