# Wildcard certificate

A public key certificate which uses an asterisk * (the wildcard) in its domain name fragment is called a Wildcard certificate. Through the use of *, a single certificate may be used for multiple sub-domains. It is commonly used for transport layer security in computer networking.

## Example

A single wildcard certificate for https://*.example.com will secure all these subdomains on the https://*.example.com domain:
* payment.example.com
* contact.example.com
* login-secure.example.com
* www.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.

## 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, in particular "partial wildcards".

## Examples

The wildcard applies only to one level of the domain name. *.example.com matches sub1.example.com but not example.com and not sub2.sub1.domain.com
The wildcard may appear anywhere inside a label as a "partial wildcard" according to early specifications
    f*.domain.com is OK. It will match frog.domain.com but not frog.super.domain.com
    baz*.example.net is OK and matches baz1.example.net
    *baz.example.net is OK and matches foobaz.example.net
    b*z.example.net is OK and matches buzz.example.net
However, use of "partial-wildcard" certs is not recommended. As of 2011, partial wildcard support is optional, and is explicitly disallowed in SubjectAltName headers that are required for multi-name certificates. All major browsers have deliberately removed support for partial-wildcard certificates; they will result in a "SSL_ERROR_BAD_CERT_DOMAIN" error. Similarly, it is typical for standard libraries in programming languages to not support "partial-wildcard" certificates. For example, any "partial-wildcard" certificate will not work with the latest versions of both Python and Go. Thus,
Do not allow a label that consists entirely of just a wildcard unless it is the left-most label
    sub1.*.domain.com is 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.com is café.com
    xn--caf-dma*.com is not allowed
    Lw*.xn--caf-dma.com is allowed